MySQL主备同步原理
1 备库io_thread通过长连接获取主库的binlog
2 备库sql_thread执行binlog
节点A和B之间互为主备关系，都认为对方是主，切换时不用再修改主备关系。
解决双M binlog循环同步问题
1 A更新的事务，binlog记的是A的server id
2 B同步后生成的binlog的server id也是A的server id
3 A继续同步时，发现server id是自己，不会处理，避免死循环。
把备库设置成只读模式的原因是
1 避免在备库上执行运维操作出现写操作
2 防止切换过程中出现双写而造成主备不一致
只读实例和双M备库区别
只读实例使用异步方式来同步binlog，存在延迟；双M备库使用同步方式，不存在延迟。
binlog有3种格式，分别是statement、row和mixed。其中，mixed是statement和row的混合场景。
statement：binlog记录SQL语句原文，占用空间小。
row：记录操作行的具体信息（包括主键id），不会有主备删除不同行的问题，占用空间大。
mixed：判断SQL语句是否可能引起主备不一致，如果可能，就用row，否则就用statement。
主备延迟
1 主库A执行完成事务，写入binlog，时刻是T1
2 备库B接收完这个binlog，时刻是T2
3 备库B执行完成这个事务，时刻是T3
同一个事务，在备库执行完成的时间和主库执行完成的时间差值。
在备库上执行show slave status，seconds_behind_master表示备库延迟了多少秒。
网络正常时，日志从主库传给备库时间很短，即T2-T1值非常小，主备延迟的主要来源是备库接收完binlog和执行完这个事务之间的时间差。
双M主备切换流程
1 判断备库B当前seconds_behind_master，如果小于某个值（比如5秒）继续下一步，否则持续重试这一步
2 主库A改成只读
3 判断备库B的seconds_behind_master，直到这个值变成0
4 备库B改成可读写
5 业务请求切到备库B