Binlog是记录所有数据库表结构变更以及表数据修改的二进制日志，不会记录SELECT和SHOW这类操作。
Binlog日志是以事件形式记录，还包含语句所执行的消耗时间。
开启Binlog日志有以下两个最重要的使用场景。
场景&&作用
- 复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。
- 恢复，用于数据库的基于时间点的还原。
内容
它记录了数据库上的所有改变，并以二进制的形式保存在磁盘中。逻辑格式的日志，可以简单认为就是执行过的事务中的sql语句。但又不完全是sql语句这么简单，而是包括了执行的sql语句（增删改）反向的信息，也就意味着delete对应着delete本身和其反向的insert；update对应着update执行前后的版本的信息；insert对应着delete和insert本身的信息。
binlog记录模式-三种格式
binlog有三种格式：Statement、Row以及Mixed。
-
基于SQL语句的复制(statement-based replication,SBR)，
每一条被修改数据的SQL都会记录到master的Binlog中，slave在复制的时候SQL进程会解析成和原来master端执行过的相同的SQL再次执行。简称SQL语句复制。
优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。
缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能，slave可与master上要保持一致会有很多相关问题。
ps：相比row能节约多少性能与日志量，这个取决于应用的SQL情况，正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，但是考虑到如果带条件的update操作，以及整表删除，alter表等操作，ROW格式会产生大量日志，因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况，其所产生的日志量会增加多少，以及带来的IO性能问题。 -
基于行的复制(row-based replication,RBR)
5.1.5版本的MySQL才开始支持row level的复制,它不记录sql语句上下文相关信息，仅保存哪条记录被修改。
优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题。
缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。
ps:新版本的MySQL中对row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录，如果sql语句确实就是update或者delete等修改数据的语句，那么还是会记录所有行的变更。 -
混合模式复制(mixed-based replication,MBR)。
从5.1.8版本开始，MySQL提供了Mixed格式，实际上就是Statement与Row的结合。
在Mixed模式下，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。
什么时候产生 即写入机制
常用的log event有：Query event、Row event、Xid event等。binlog文件的内容就是各种Log event的集合。
根据记录模式和操作触发event事件生成log event（事件触发执行机制）
将事务执行过程中产生log event写入缓冲区，每个事务线程都有一个缓冲区
Log Event保存在一个binlog_cache_mngr数据结构中，在该结构中有两个缓冲区，一个是stmt_cache，用于存放不支持事务的信息；另一个是trx_cache，用于存放支持事务的信息。
事务在提交阶段会将产生的log event写入到外部binlog文件中。
不同事务以串行方式将log event写入binlog文件中，所以一个事务包含的log event信息在binlog文件中是连续的，中间不会插入其他事务的log event。
事务提交的时候，一次性将事务中的sql语句（一个事物可能对应多个sql语句）按照一定的格式记录到binlog中。
这里与redo log很明显的差异就是redo log并不一定是在事务提交的时候刷新到磁盘，redo log是在事务开始之后就开始逐步写入磁盘。
因此对于事务的提交，即便是较大的事务，提交（commit）都是很快的，但是在开启了bin_log的情况下，对于较大事务的提交，可能会变得比较慢一些。这是因为binlog是在事务提交的时候一次性写入的造成的。
什么时候释放
binlog的默认是保持时间由参数expire_logs_days配置，也就是说对于非活动的日志文件，在生成时间超过expire_logs_days配置的天数之后，会被自动删除。
对应的物理文件
配置文件的路径为log_bin_basename，binlog日志文件按照指定大小，当日志文件达到指定的最大的大小之后，进行滚动更新，生成新的日志文件。
对于每个binlog日志文件，通过一个统一的index文件来组织。
其他：
二进制日志的作用之一是还原数据库的，这与redo log很类似，很多人混淆过，但是两者有本质的不同
- 作用不同：redo log是保证事务的持久性的，是事务层面的，binlog作为还原的功能，是数据库层面的（当然也可以精确到事务层面的），虽然都有还原的意思，但是其保护数据的层次是不一样的。
- 内容不同：redo log是物理日志，是数据页面的修改之后的物理记录，binlog是逻辑日志，可以简单认为记录的就是sql语句
另外，两者日志产生的时间，可以释放的时间，在可释放的情况下清理机制，都是完全不同的。 - 恢复数据时候的效率，基于物理日志的redo log恢复数据的效率要高于语句逻辑日志的binlog
- Redo Log是属于InnoDB引擎功能，Binlog是属于MySQL Server自带功能，并且是以二进制文件记录。
- Redo Log日志是循环写，日志空间大小是固定，Binlog是追加写入，写完一个写下一个，不会覆盖使用。
- Redo Log作为服务器异常宕机后事务数据自动恢复使用，Binlog可以作为主从复制和数据恢复使用。Binlog没有自动crash-safe能力。
(crash-safe 即在 InnoDB 存储引擎中，事务提交过程中任何阶段，MySQL突然奔溃，重启后都能保证事务的完整性，已提交的数据不会丢失，未提交完整的数据会自动进行回滚。这个能力依赖的就是redo log和unod log两个日志。)
关于事务提交时，redo log和binlog的写入顺序，为了保证主从复制时候的主从一致（当然也包括使用binlog进行基于时间点还原的情况），是要严格一致的，MySQL通过两阶段提交过程来完成事务的一致性的，也即redo log和binlog的一致性的，理论上是先写redo log，再写binlog，两个日志都提交成功（刷入磁盘），事务才算真正的完成。
当停止或重启服务器时，服务器会把日志文件记入下一个日志文件，Mysql会在重启时生成一个新的日志文件，文件序号递增；此外，如果日志文件超过max_binlog_size（默认值1G）系统变量配置的上限时，也会生成新的日志文件（在这里需要注意的是，如果你正使用大的事务，二进制日志还会超过max_binlog_size，不会生成新的日志文件，事务全写入一个二进制日志中,这种情况主要是为了保证事务的完整性）；日志被刷新时，新生成一个日志文件。每当重启一次，就会自动生成一个binlog文件。
mysql> flush logs;
Query OK, 0 rows affected (0.07 sec)
mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 167 |
| mysql-bin.000002 | 120 |
+------------------+-----------+
2 rows in set (0.00 sec)
操作
- 暂时关闭binlog
set SQL_LOG_BIN=0;
# 执行开启语句
set global log_bin=mysqllogbin;
- 查看binlog的方式 show variables like ‘%binlog_format%’
mysql> show variables like '%binlog_format%';
+---------------+-----------+
| Variable_name | Value |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+
1 row in set (0.01 sec)
- 查看bin-log是否启用 show variables like ‘%binlog%’
mysql> show variables like '%binlog%';
+-----------------------------------------+----------------------+
| Variable_name | Value |
+-----------------------------------------+----------------------+
| binlog_cache_size | 32768 |
| binlog_checksum | CRC32 |
| binlog_direct_non_transactional_updates | OFF |
| binlog_error_action | IGNORE_ERROR |
| binlog_format | STATEMENT |
| binlog_gtid_simple_recovery | OFF |
| binlog_max_flush_queue_time | 0 |
| binlog_order_commits | ON |
| binlog_row_image | FULL |
| binlog_rows_query_log_events | OFF |
| binlog_stmt_cache_size | 32768 |
| binlogging_impossible_mode | IGNORE_ERROR |
| innodb_api_enable_binlog | OFF |
| innodb_locks_unsafe_for_binlog | OFF |
| max_binlog_cache_size | 18446744073709547520 |
| max_binlog_size | 1073741824 |
| max_binlog_stmt_cache_size | 18446744073709547520 |
| simplified_binlog_gtid_recovery | OFF |
| sync_binlog | 0 |
+-----------------------------------------+----------------------+
19 rows in set (0.00 sec)
-
打开bin-log的方法
默认情况下bin-log是关闭的，需要修改my.cnf文件，
添加log-bin=mysql-bin至文件中，然后重启mysql服务即可。 -
获取bin-log文件列表 show binary logs
mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 754 |
+------------------+-----------+
1 row in set (0.00 sec)
- 获取当前写入bin-log文件 show master status
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 | 754 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
- 查看当前bin-long文件内容 show binlog events
mysql> show binlog events;
+------------------+-----+-------------+-----------+-------------+-------------------------------------------------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+------------------+-----+-------------+-----------+-------------+-------------------------------------------------------------------------------------------------------------+
| mysql-bin.000001 | 4 | Format_desc | 1 | 120 | Server ver: 5.6.23-log, Binlog ver: 4 |
| mysql-bin.000001 | 120 | Query | 1 | 203 | BEGIN |
| mysql-bin.000001 | 203 | Intvar | 1 | 235 | INSERT_ID=100012 |
| mysql-bin.000001 | 235 | Query | 1 | 406 | use `testdb`; INSERT INTO `user` (`firstname`, `lastname`, `age`, `province`) VALUES('Jack2', '102', 21, 2) |
| mysql-bin.000001 | 406 | Xid | 1 | 437 | COMMIT /* xid=159 */ |
| mysql-bin.000001 | 437 | Query | 1 | 520 | BEGIN |
| mysql-bin.000001 | 520 | Intvar | 1 | 552 | INSERT_ID=100014 |
| mysql-bin.000001 | 552 | Query | 1 | 723 | use `testdb`; INSERT INTO `user` (`firstname`, `lastname`, `age`, `province`) VALUES('Jack2', '102', 21, 1) |
| mysql-bin.000001 | 723 | Xid | 1 | 754 | COMMIT /* xid=243 */ |
+------------------+-----+-------------+-----------+-------------+-------------------------------------------------------------------------------------------------------------+
9 rows in set (0.00 sec)
- 查看指定bin-log文件内容 show binlog events in ‘mysql-bin.000001’
mysql> show binlog events in 'mysql-bin.000001';
+------------------+-----+-------------+-----------+-------------+-------------------------------------------------------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+------------------+-----+-------------+-----------+-------------+-------------------------------------------------------------------------------------------------------------+
| mysql-bin.000001 | 4 | Format_desc | 1 | 120 | Server ver: 5.6.23-log, Binlog ver: 4 |
| mysql-bin.000001 | 120 | Query | 1 | 203 | BEGIN |
| mysql-bin.000001 | 203 | Intvar | 1 | 235 | INSERT_ID=100012 |
| mysql-bin.000001 | 235 | Query | 1 | 406 | use `testdb`; INSERT INTO `user` (`firstname`, `lastname`, `age`, `province`) VALUES('Jack2', '102', 21, 2) |
| mysql-bin.000001 | 406 | Xid | 1 | 437 | COMMIT /* xid=159 */ |
| mysql-bin.000001 | 437 | Query | 1 | 520 | BEGIN |
| mysql-bin.000001 | 520 | Intvar | 1 | 552 | INSERT_ID=100014 |
| mysql-bin.000001 | 552 | Query | 1 | 723 | use `testdb`; INSERT INTO `user` (`firstname`, `lastname`, `age`, `province`) VALUES('Jack2', '102', 21, 1) |
| mysql-bin.000001 | 723 | Xid | 1 | 754 | COMMIT /* xid=243 */ |
+------------------+-----+-------------+-----------+-------------+-------------------------------------------------------------------------------------------------------------+
9 rows in set (0.00 sec)
- 设置bin-log过期时间 set global expire_logs_days=3
mysql> show variables like 'expire_logs_days';
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| expire_logs_days | 0 |
+------------------+-------+
1 row in set (0.00 sec)
mysql> set global expire_logs_days=3;
Query OK, 0 rows affected (0.00 sec)
- 手动清理所有bin-log
mysql> reset master;
Query OK, 0 rows affected (0.07 sec)
mysql> reset slave;
- 手动清理部分bin-log
mysql> purge master logs before '2012-03-30 17:20:00';//删除指定日期以前的日志索引中binlog日志文件
Query OK, 0 rows affected, 1 warning (0.01 sec)
mysql> purge master logs to 'mysql-bin.000001';//删除指定日志文件的日志索引中binlog日志文件
Query OK, 0 rows affected (0.02 sec)4. Bin-log扩展
- 使用binlog恢复数据
//按指定时间恢复
mysqlbinlog --start-datetime="2020-04-25 18:00:00" --stop-datetime="2020-04-26 00:00:00" mysqlbinlog.000002 | mysql uroot -p1234
//按事件位置号恢复
mysqlbinlog --start-position=154 --stop-position=957 mysqlbinlog.000002 | mysql -uroot -p1234
binlog同步工具
- go-mysql-transfer (golang)
- canal （java）
- mysql_stream （python）
2623
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
