目录
binlog 介绍
记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。
作用：
- 复制：MySQL Replication在Master端开启binlog，Master把它的二进制日志传递给slaves并回放来达到master-slave数据一致的目的
- 数据恢复：通过mysqlbinlog工具恢复数据
存储格式：二进制
存储内容：
记录更改数据的语句，不存 select 和 show 等查询语句，查询语句可以通过 access.log 查看
影响：
开启binlog会使性能稍微变慢
管理 binlog
配置
开启binlog
修改 /etc/my.cnf，在配置文件中加入 log-bin 配置，表示启用binlog，如果没有给定值，写成 log-bin=，则默认名称为主机名。（注：名称若带有小数点，则只取第一个小数点前的部分作为名称）
[mysqld]
log-bin=my-binlog-name也可以通过 SET SQL_LOG_BIN=1 命令来启用 binlog，通过 SET SQL_LOG_BIN=0 命令停用 binlog。启用 binlog 之后须重启MySQL才能生效。
ps：查看mysql进程指定的配置文件，如果没有则是读取的默认配置文件。查看msyql默认读取的my.cnf目录
mysql --help | grep 'my.cnf'顺序排前的优先
日志文件名
binlog日志文件有两种：
- 索引文件，后缀为 .index，用于记录所有有效的二进制文件
- 二进制文件，后缀为.0000*，记录数据库所有的DDL和DML事件
以下3种情况会创建一个新的日志文件：
- 重新启动mysql
- 刷新日志
- 日志文件大小达到 max_binlog_size
日志文件实际可能会比max_binlog_size大一点，因为事务是整体写入文件的，从不在文件之间拆分
日志内容
# 查看binlog记录的事件
show binlog events;
binlog是一个二进制文件集合，每个binlog文件以一个4字节的魔数开头，接着是一组Events:
- 魔数：0xfe62696e对应的是0xfebin；
- Event：每个Event包含header和data两个部分；header提供了Event的创建时间，哪个服务器等信息，data部分提供的是针对该Event的具体信息，如具体数据的修改；
- 第一个Event用于描述binlog文件的格式版本，这个格式就是event写入binlog文件的格式；
- 其余的Event按照第一个Event的格式版本写入；
- 最后一个Event用于说明下一个binlog文件；
- binlog的索引文件是一个文本文件，其中内容为当前的binlog文件列表
max_binlog_size 的最小值是4096字节，最大值和默认值是 1GB (1073741824字节)。事务被写入到binlog的一个块中，所以它不会在几个二进制日志之间被拆分。因此，如果你有很大的事务，为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的日志都记录到当前日志文件中，直到事务结束，你可能会看到binlog文件大于 max_binlog_size 的情况。
日志格式
- STATEMENT：基于SQL语句的复制（statement-based replication, SBR），
MySQL 5.7.7之前的默认格式 - ROW：基于行的复制（row-based replication, RBR），默认使用BASE64编码，需要解码，
MySQL 5.7.7之后的默认格式 - MIXED：混合模式复制（mixed-based replication, MBR），推荐使用
STATEMENT格式可能会导致主从不一致，
例如使用以下函数的语句无法被正确复制：
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非启动时启用了 –sysdate-is-now 选项)
修改日志格式，或set global binlog_format=ROW;
[mysqld]
binlog_format=ROWStatement
优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO, 提高了性能。
每一条会修改数据的sql都会记录在binlog中
缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行的时候相同的结果。另外mysql的复制，像一些特定函数的功能，slave与master要保持一致会有很多相关问题。
Row
优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以row的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题
5.1.5版本的MySQL才开始支持row level的复制,它不记录sql语句上下文相关信息，仅保存哪条记录被修改。
缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。
Mixed
从5.1.8版本开始，MySQL提供了Mixed格式，实际上就是Statement与Row的结合。
在Mixed模式下，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。
mysqlbinlog 工具
由于binlog文件内容是二进制格式，可以使用官方提供的 mysqlbinlog 工具来查看
mysqlbinlog [options] log-files
# 查看bin-log二进制文件（带查询条件）
mysqlbinlog -vv --base64-output=decode-rows /var/lib/mysql/binlog.000001 \
--start-datetime="2023-06-01 00:00:00" \
--stop-datetime="2023-06-30 00:00:00" \
--start-position="4" \
--stop-position="500" \
-d database_name执行后，输出如下内容
截取一段来简单说明下：
# at 1653
#230605 21:04:05 server id 1 end_log_pos 1792 CRC32 0x287f5a5d Query thread_id=8 exec_time=183 error_code=0
SET TIMESTAMP=1685970245/*!*/;
insert into test2 values(1, 'ryan', 1)
/*!*/;上面输出包括信息：
- position: 位于文件中的位置，即第一行的（# at 1653）,说明该事件记录从文件第1653个字节开始
- timestamp: 事件发生的时间戳，即第二行的（#230605 21:04:05 ）
- server id: 服务器标识（1）
- end_log_pos 表示下一个事件开始的位置（即当前事件的结束位置+1）
- thread_id: 执行该事件的线程id （thread_id=8）
- CRC32 0x287f5a5d：CRC32是一种用于校验数据完整性的校验和算法。CRC32算法可以将数据转换为一个32位的校验和值，用于检测数据是否被篡改或损坏
- exec_time: 事件执行的花费时间
- error_code: 错误码，0意味着没有发生错误
- type:事件类型Query
实践
一般恢复逻辑，每天备份，根据具体的时间点找到对应的binlog，使用mysqlbinlog导出，然后剔除掉误操作的SQL，在新的库上进行重放，然后在替换线上的表，或者使用以下方式直接导入被删除的数据：
使用mysqlbinlog工具将备份文件中的删除操作反向执行需要满足以下两个条件：
- MySQL数据库启用了二进制日志（binlog）功能，且备份文件中包含了二进制日志文件。
- MySQL数据库使用了基于语句的复制（statement-based replication）或混合复制（mixed-based replication）方式，而不是基于行的复制（row-based replication）方式。
然后使用以下方法恢复
- 使用mysqlbinlog工具将备份文件中的二进制日志转换为SQL语句。例如，假设备份文件名为backup.binlog，可以使用以下命令将其转换为SQL语句：
mysqlbinlog backup.binlog > backup.sql- 打开备份文件的SQL语句，查找包含删除操作的语句。例如，假设要恢复的表名为mytable，可以使用以下命令查找包含删除操作的语句：
grep -i 'delete from mytable' backup.sql
- 将包含删除操作的语句复制到一个新的SQL文件中，并将其中的DELETE关键字替换为INSERT关键字。例如，假设要恢复的数据为(id, name, age)，可以使用以下命令将删除操作转换为插入操作：
sed -e 's/^DELETE FROM mytable/INSERT INTO mytable/g' \
-e 's/ WHERE .*$//' \
-e "s/'/''/g" \
backup.sql > restore.sql
在这个命令中，使用sed命令将DELETE关键字替换为INSERT关键字，并删除WHERE子句。同时，还将单引号转义为两个单引号，以避免SQL注入等问题。
- 执行新的SQL文件，将删除的数据插入到数据库中。例如，可以使用以下命令执行新的SQL文件：
mysql -u username -p password database < restore.sql日志产生的性能影响：
由于日志的记录带来的直接性能损耗就是数据库系统中最为昂贵的IO资源。
MySQL的日志主要包括错误日志（ErrorLog），二进制日志（Binlog），查询日志（QueryLog），慢查询日志（SlowQueryLog）等。
在默认情况下，系统仅仅打开错误日志，关闭了其他所有日志，以达到尽可能减少IO损耗提高系统性能的目的。
但是在一般稍微重要一点的实际应用场景中，都至少需要打开二进制日志，因为这是MySQL很多存储引擎进行增量备份的基础，也是MySQL实现复制的基本条件。
有时候为了进一步的mysql性能优化，定位执行较慢的SQL语句，很多系统也会打开慢查询日志来记录执行时间超过特定数值（由我们自行设置）的SQL语句。
一般情况下，在生产系统中很少有系统会打开查询日志。因为查询日志打开之后会将MySQL中执行的每一条Query都记录到日志中，会该系统带来比较大的IO负担，而带来的实际效益却并不是非常大。一般只有在开发测试环境中，为了定位某些功能具体使用了哪些SQL语句的时候，才会在短时间段内打开该日志来做相应的分析。
所以，在MySQL系统中，会对性能产生影响的MySQL日志（不包括各存储引擎自己的日志）主要就是Binlog了。
查询数据的变化
日常工作中，经常需要排查数据变更之前是什么值，才能定位到bug的原因，一般需要提供大概的时间范围、当前字段的值以及一些其他可以缩小范围的字段值
官方文档：
https://dev.mysql.com/doc/refman/5.7/en/binary-log.html
附：常用binlog操作命令
# 一、配置信息
# 是否启用binlog日志
show variables like 'log_bin';
# 查看详细的日志配置信息
show global variables like '%log%';
# mysql数据存储目录
show variables like '%dir%';
# 查看binlog的目录
show global variables like "%log_bin%";
# 查看当前服务器使用的binlog文件及大小
show binary logs;
# 查看主服务器使用的binlog文件及大小
# 二、管理binlog
# 查看所有binlog的日志列表
show master logs;
# 查看最后一个binlog日志的编号名称及最后一个时间结束的位置pos
show master status;
# 刷新binlog，会生成一个新编号的binlog日志文件
flush log;
# 清空所有binlog日志（慎用）
reset master;
# 设置binlog文件保存事件，过期删除，单位天
set global expire_log_days=3;
# 删除指定日期前的日志索引中binlog日志文件
purge master logs before '2019-03-09 14:00:00';
# 删除指定日志文件
purge master logs to 'master.000003';
# 删除slave的中继日志
reset slave;
# 三、事件查询命令
# 查看 binlog 内容
show binlog events;
# 查看具体一个binlog文件的内容 （in 后面为binlog的文件名）
show binlog events in 'master.000001';
# IN 'log_name' ：指定要查询的binlog文件名(不指定就是第一个binlog文件)
# FROM pos ：指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
# LIMIT [offset,] ：偏移量(不指定就是0)
# row_count ：查询总条数(不指定就是所有行)
show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];my.cnf 配置
binlog_format = MIXED //binlog日志格式
log_bin =目录/mysql-bin.log //binlog日志名
expire_logs_days = 7 //binlog过期清理时间
max_binlog_size = 100m //binlog每个日志文件大小
binlog-do-db=需要备份的数据库名，如果备份多个数据库，重复设置这个选项即可
binlog-ignore-db=不需要备份的数据库苦命，如果备份多个数据库，重复设置这个选项即可“binlog_cache_size”：在事务过程中容纳二进制日志SQL语句的缓存大小。二进制日志缓存是服务器支持事务存储引擎并且服务器启用了二进制日志(—log-bin选项)的前提下为每个客户端分配的内存，注意，是每个Client都可以分配设置大小的binlogcache空间。如果读者朋友的系统中经常会出现多语句事务的华，可以尝试增加该值的大小，以获得更有的性能。当然，我们可以通过MySQL的以下两个状态变量来判断当前的binlog_cache_size的状况：Binlog_cache_use和Binlog_cache_disk_use。
“max_binlog_cache_size”：和”binlog_cache_size”相对应，但是所代表的是binlog能够使用的最大cache内存大小。当我们执行多语句事务的时候，max_binlog_cache_size如果不够大的话，系统可能会报出“Multi-statementtransactionrequiredmorethan’max_binlog_cache_size’bytesofstorage”的错误。
“max_binlog_size”：Binlog日志最大值，一般来说设置为512M或者1G，但不能超过1G。该大小并不能非常严格控制Binlog大小，尤其是当到达Binlog比较靠近尾部而又遇到一个较大事务的时候，系统为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进入当前日志，直到该事务结束。这一点和Oracle的Redo日志有点不一样，因为Oracle的Redo日志所记录的是数据文件的物理位置的变化，而且里面同时记录了Redo和Undo相关的信息，所以同一个事务是否在一个日志中对Oracle来说并不关键。而MySQL在Binlog中所记录的是数据库逻辑变化信息，MySQL称之为Event，实际上就是带来数据库变化的DML之类的Query语句。
“sync_binlog”：这个参数是对于MySQL系统来说是至关重要的，他不仅影响到Binlog对MySQL所带来的性能损耗，而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下：
sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让Filesystem自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。
sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。
在MySQL中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。
另：
MySQL的复制（Replication），实际上就是通过将Master端的Binlog通过利用IO线程通过网络复制到Slave端，然后再通过SQL线程解析Binlog中的日志再应用到数据库中来实现的。所以，Binlog量的大小对IO线程以及Msater和Slave端之间的网络都会产生直接的影响。
MySQL中Binlog的产生量是没办法改变的，只要我们的Query改变了数据库中的数据，那么就必须将该Query所对应的Event记录到Binlog中。那我们是不是就没有办法优化复制了呢？当然不是，在MySQL复制环境中，实际上是是有8个参数可以让我们控制需要复制或者需要忽略而不进行复制的DB或者Table的，分别为：
Binlog_Do_DB：设定哪些数据库（Schema）需要记录Binlog；
Binlog_Ignore_DB：设定哪些数据库（Schema）不要记录Binlog；
Replicate_Do_DB：设定需要复制的数据库（Schema），多个DB用逗号（“,”）分隔；
Replicate_Ignore_DB：设定可以忽略的数据库（Schema）；
Replicate_Do_Table：设定需要复制的Table；
Replicate_Ignore_Table：设定可以忽略的Table；
Replicate_Wild_Do_Table：功能同Replicate_Do_Table，但可以带通配符来进行设置；
Replicate_Wild_Ignore_Table：功能同Replicate_Ignore_Table，可带通配符设置；
通过上面这八个参数，我们就可以非常方便按照实际需求，控制从Master端到Slave端的Binlog量尽可能的少，从而减小Master端到Slave端的网络流量，减少IO线程的IO量，还能减少SQL线程的解析与应用SQL的数量，最终达到改善Slave上的数据延时问题。
实际上，上面这八个参数中的前面两个是设置在Master端的，而后面六个参数则是设置在Slave端的。虽然前面两个参数和后面六个参数在功能上并没有非常直接的关系，但是对于优化MySQL的Replication来说都可以启到相似的功能。当然也有一定的区别，其主要区别如下：
如果在Master端设置前面两个参数，不仅仅会让Master端的Binlog记录所带来的IO量减少，还会让Master端的IO线程就可以减少Binlog的读取量，传递给Slave端的IO线程的Binlog量自然就会较少。这样做的好处是可以减少网络IO，减少Slave端IO线程的IO量，减少Slave端的SQL线程的工作量，从而最大幅度的优化复制性能。当然，在Master端设置也存在一定的弊端，因为MySQL的判断是否需要复制某个Event不是根据产生该Event的Query所更改的数据
所在的DB，而是根据执行Query时刻所在的默认Schema，也就是我们登录时候指定的DB或者运行“USEDATABASE”中所指定的DB。只有当前默认DB和配置中所设定的DB完全吻合的时候IO线程才会将该Event读取给Slave的IO线程。所以如果在系统中出现在默认DB和设定需要复制的DB不一样的情况下改变了需要复制的DB中某个Table的数据的时候，该Event是不会被复制到Slave中去的，这样就会造成Slave端的数据和Master的数据不一致的情况出现。同样，如果在默认Schema下更改了不需要复制的Schema中的数据，则会被复制到Slave端，当Slave端并没有该Schema的时候，则会造成复制出错而停止。
而如果是在Slave端设置后面的六个参数，在性能优化方面可能比在Master端要稍微逊色一点，因为不管是需要还是不需要复制的Event都被会被IO线程读取到Slave端，这样不仅仅增加了网络IO量，也给Slave端的IO线程增加了RelayLog的写入量。但是仍然可以减少Slave的SQL线程在Slave端的日志应用量。虽然性能方面稍有逊色，但是在Slave端设置复制过滤机制，可以保证不会出现因为默认Schema的问题而造成Slave和Master数据不一致或者复制出错的问题。