概念

binlog 用于记录数据库执行的写入性操作信息，以二进制的形式保存在磁盘上。

binlog 是 MySQL 的逻辑日志，由 Server 层记录，使用任何存储引擎都会记录binlog日志

• 逻辑日志：可以简单理解为记录的就是SQL语句
• 物理日志：MySQL 最终的数据都存在数据页中，物理日志记录的就是数据页的变更

binlog 通过追加的方式写入，可以通过

max_binlog_size

参数配置binlog文件的大小，当文件大小达到给定的定值后，会生成新的文件来保存日志

使用场景

• 主从复制：在 Master 端开启 binlog，然后将 binlog 发送到各个 Slave 端，Slave 端通过重放 binlog 从而达到主从数据一致。
• 数据恢复：通过使用 mysqlbinlog 工具来恢复数据。

binlog 刷盘

对于 InnoDB 存储引擎，在事务提交后，才会记录 binlog 日志，此时日志在内存中，通过参数

sync_binlog

控制刷盘时间，sync_binlog 值有以下几种：

• 0：事务提交，不刷盘，由操作系统自行判断何时写入磁盘
• 1：每次事务提交的时候，都将 binlog 写入磁盘
• N：每 N 个事务提交，才会将 binlog 写入磁盘

设置为1最安全，设置大于1的值，可以提升数据库的部分性能，但同时会造成数据不一致的问题

binlog 日志格式

binlog 有三种格式，分为 STATEMENT，ROW 和 MIXED

5.7.7 之前，默认格式是 STATEMENT，5.7.7 之后，默认是 ROW

• STATEMENT：基于SQL语句的复制，每一条会修改数据的SQL语句会记录到 binlog 中。

  • 优点：不需要记录每一行的变化，减少了 binlog 日志量，节约IO，从而提高性能。
  • 缺点：在某些情况下会导致主从数据不一致，比如执行 sysdate()，slepp()

• ROW：基于行的复制，不记录每条SQL语句的上下文信息，仅需记录哪条数据被修改了

  • 优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题
  • 缺点：会产生大量的日志，尤其是 alter table 的时候会让日志暴涨

• MIXED：基于STATEMENT 和 ROW 两种模式的混合复制，一般的复制使用 STATEMENT 模式保存 binlog，对于 STATEMENT 模式无法复制的操作使用 ROW 模式保存 binlog

参考资料

• 
  https://blog.csdn.net/u013256816/article/details/108505371