【MySQL】binlog

1. 简介
     binlog 是逻辑日志，记录内容是语句的原始逻辑，类似于“给 ID=2 这一行的 c 字段加 1”，属于MySQL Server 层。 不管用什么存储引擎，只要发生了表数据更新，都会产生 binlog 日志。

2. binlog的使用场景
     MySQL数据库的数据备份、主备、主主、主从都离不开binlog，需要依靠binlog来同步数据，保证数据一致性。

3. 记录格式
     binlog 日志有三种格式，可以通过binlog_format参数指定。

  ① Statement
  记录的内容是SQL语句原文，比如执行一条update T set update_time=now() where id=1，记录的内容如下。

  同步数据时，会执行记录的SQL语句，但是有个问题，update_time=now()这里会获取当前系统时间，直接执行会导致与原库的数据不一致。为了解决这种问题，我们需要指定为row。

  ② row
  记录的内容不再是简单的SQL语句了，而是操作的具体数据，能体现更新前和更新后的数据，记录内容如下。

  row格式记录的内容看不到详细信息，要通过mysqlbinlog工具解析出来。
  update_time=now()变成了具体的时间update_time=1627112756247，条件后面的@1、@2、@3 都是该行数据第 1 个~3 个字段的原始值（假设这张表只有 3 个字段）。
  这样就能保证同步数据的一致性，通常情况下都是指定为row，这样可以为数据库的恢复与同步带来更好的可靠性。但是这种格式，需要更大的容量来记录，比较占用空间，恢复与同步时会更消耗IO资源，影响执行速度。
所以就有了一种折中的方案，指定为mixed，记录的内容是前两者的混合。

  ③ mixed
  MySQL会判断这条SQL语句是否可能引起数据不一致，如果是，就用row格式，否则就用statement格式。

4. 刷盘策略
     binlog日志刷盘流程如下。

  上图的 write，是指把日志写入到文件系统的 page cache，并没有把数据持久化到磁盘，所以速度比较快。上图的 fsync，才是将数据持久化到磁盘的操作。
  write和fsync的时机，可以由参数sync_binlog控制，默认是0。
  ① 0：为0的时候，表示每次提交事务都只write，由系统自行判断什么时候执行fsync。虽然性能得到提升，但是机器宕机，page cache里面的 binglog 会丢失。
  ② 1：为了安全起见，可以设置为1，表示每次提交事务都会执行fsync，就如同redo log 日志的默认刷盘策略一样。
  ③ N：最后还有一种折中方式，可以设置为N(N>1)，表示每次提交事务都write，但累积N个事务后才fsync。