为何binlog有mixed格式？
因为有些statement格式的binlog可能会导致主备不一致，所以要使用row格式。
但row很占空间（不然怎么叫肉呢？）。比如你用一个delete语句删掉10万行：
- statement就是一个SQL语句被记录到binlog，占用几十个字节
- row就要把这10万条记录都写到binlog。不仅占用巨大空间，写binlog也要耗费I/O资源，影响执行速度。
所以，MySQL采取折中方案-mixed：MySQL自己会判断该SQL是否可能引起主备不一致：
- 有可能，用row
- 不可能，用statement
即mixed既可以利用statment格式的优点，又能避免数据不一致。
比如我们的例子，设为mixed后：
- 就会记录为row
- 若执行的语句没有limit 1，就记录为statement
现在越来越多的场景要求把MySQL的binlog格式设成row。这么做的理由有很多，比如恢复数据。
数据恢复的重要性
- 即使执行delete，row格式binlog也会保存被删掉的行的整行信息。所以，若你在执行完一条delete后，发现删错数据了，可以直接把binlog中记录的delete转insert，把错删数据插回。
- 若执行错insert呢？row下，insert的binlog里会记录所有字段信息，可以用来定位被插入的那行。再直接把insert转delete 即可。
若执行update，binlog会记录修改前整行的数据和修改后的整行数据。所以只需把这个event前后两行信息对调，在DB里执行
虽然mixed格式的binlog现在已经用得不多了，但这里还是要再借用一下mixed格式来说明一个问题，来看一下这条SQL语句：
insert into ttt values(10,10, now());
若binlog设为mixed，MySQL会把它记录为啥格式呢？
MySQL采用statement格式。若该binlog过了1min才传给备库，那主备数据不就不一致了？
再用mysqlbinlog查看：
binlog在记录event时，多记了一条命令：SET TIMESTAMP。它用 SET TIMESTAMP命令约定了接下来的now()函数的返回时间。
因此，无论该binlog多久后被备库执行或用于恢复该库的备份，该insert插入的行，值都固定。即通过SET TIMESTAMP，MySQL保证了主备数据一致性。
有人重放binlog时，是这么做的：
- 用mysqlbinlog解析出日志
- 然后把里面的statement语句直接拷贝出来执行
这样有风险。因为有些语句的执行结果依赖于上下文命令，直接执行很可能错误。
使用binlog恢复数据的正确做法：
- 用 mysqlbinlog工具解析出来
- 然后把解析结果整个发给MySQL执行。类似下面的命令：
mysqlbinlog master.000001 --start-position=2738 --stop-position=2973 | mysql -h127.0.0.1 -P13000 -u$user -p$pwd;
将 master.000001 文件里面从第2738字节到第2973字节中间这段内容解析出来，放到MySQL去执行。
循环复制问题
binlog确保了在备库执行相同的binlog，可以得到与主库相同的状态。
因此，可以认为正常情况下主备数据是一致的。即文章一开始的图中A、B两个节点的内容是一致的。不过那是M-S结构，实际生产上使用比较多的是双M结构：
- MySQL主备切换流程–双M结构
- 区别只是多了一条线，即：节点A和B之间总是互为主备关系。这样在切换的时候就不用再修改主备关系。
但是，双M结构还有一个问题需要解决：业务逻辑在节点A上更新了一条语句，然后再把生成的binlog 发给节点B，节点B执行完这条更新语句后也会生成binlog。（推荐把参数log_slave_updates设置为on，表示备库执行relay log后生成binlog）。
那么，若节点A同时是节点B的备库，相当于又把节点B新生成的binlog拿过来执行了一次，然后节点A和B间，会不断地循环执行这个更新语句，也就是循环复制了。这怎么解决？
我们已经知道，MySQL在binlog中记录了这个命令第一次执行时所在实例的server id。因此，可以用下面的逻辑解决两个节点间的循环复制的问题：
- 规定两个库的server id必须不同，如果相同，则它们之间不能设定为主备关系
- 一个备库接到binlog并在重放的过程中，生成与原binlog的server id相同的新的binlog
- 每个库在收到从自己的主库发过来的日志后，先判断server id，如果跟自己的相同，表示这个日志是自己生成的，就直接丢弃这个日志
按照这个逻辑，如果我们设置了双M结构，日志的执行流就会变成这样：
4. 从节点A更新的事务，binlog里面记的都是A的server id
5. 传到节点B执行一次以后，节点B生成的binlog 的server id也是A的server id
6. 再传回给节点A，A判断到这个server id与自己的相同，就不会再处理这个日志。所以，死循环在这里就断掉了
binlog在MySQL高可用方案很重要，是所有MySQL高可用方案，诸如多节点、半同步、MySQL group replication等的基础。
