一、前言
涉及到的东西：两阶段提交，binlog三种格式
1、两阶段提交
在持久化 redo log 和 binlog 这两份日志的时候，如果出现半成功的状态，就会造成主从环境的数据不一致性。这是因为 redo log 影响主库的数据，binlog 影响从库的数据，所以 redo log 和 binlog 必须保持一致才能保证主从数据一致。
从图中可看出，事务的提交过程有两个阶段，就是将 redo log 的写入拆成了两个步骤：prepare 和 commit，中间再穿插写入binlog，具体如下：
prepare 阶段：将 XID（内部 XA 事务的 ID） 写入到 redo log，同时将 redo log 对应的事务状态设置为 prepare，然后将 redo log 持久化到磁盘（innodb_flush_log_at_trx_commit = 1 的作用）；
commit 阶段：把 XID 写入到 binlog，然后将 binlog 持久化到磁盘（sync_binlog = 1 的作用），接着调用引擎的提交事务接口，将 redo log 状态设置为 commit，此时该状态并不需要持久化到磁盘，只需要 write 到文件系统的 page cache 中就够了，因为只要 binlog 写磁盘成功，就算 redo log 的状态还是 prepare 也没有关系，一样会被认为事务已经执行成功；
两阶段提交是以 binlog 写成功为事务提交成功的标识，因为 binlog 写成功了，就意味着能在 binlog 中查找到与 redo log 相同的 XID。
2、bin log三种格式
binlog 有 3 种格式类型，分别是 STATEMENT（默认格式）、ROW、 MIXED，区别如下：
STATEMENT：每一条修改数据的 SQL 都会被记录到 binlog 中（相当于记录了逻辑操作，所以针对这种格式， binlog 可以称为逻辑日志），主从复制中 slave 端再根据 SQL 语句重现。但 STATEMENT 有动态函数的问题，比如你用了 uuid 或者 now 这些函数，你在主库上执行的结果并不是你在从库执行的结果，这种随时在变的函数会导致复制的数据不一致；
ROW：记录行数据最终被修改成什么样了（这种格式的日志，就不能称为逻辑日志了），不会出现 STATEMENT 下动态函数的问题。但 ROW 的缺点是每行数据的变化结果都会被记录，比如执行批量 update 语句，更新多少行数据就会产生多少条记录，使 binlog 文件过大，而在 STATEMENT 格式下只会记录一个 update 语句而已；
MIXED：包含了 STATEMENT 和 ROW 模式，它会根据不同的情况自动使用 ROW 模式和 STATEMENT 模式；
二、bin log 如何写入
statement：记录的是原始语句；
row：记录的是行的变化；
mixed：根据需要进行选择
因为statement存在unsafe问题，row存在格式太大问题，所以要自行进行选择
三、双M架构下循环复制问题
• 说明：节点A和节点B之间互为主备关系，互为slave，存在循环复制问题
• 解决：binlog中会记录server id，每个库在收到主库发过来的binlog⽇志时，先判断 server id，如果与⾃⼰的相同说明是⾃⼰⽣成的，就会直接丢弃这个⽇志
四、主从延迟原因？如何解决
▪ 并行复制：MySQL 5.6 版本以后，提供了⼀种并行复制的⽅式，通过将 SQL 线程转换为多 个 work 线程来进行重放（解决主从同步时延问题）
▪ 半同步复制：主库收到⾄少⼀个ack就认为写操作完成（解决主库数据丢失问题）
▪ 提⾼机器配置
▪ 避免单表单库太大
▪ 避免长事务
▪ 避免让数据库做大量运算
▪ 对延迟敏感的业务，直接用主库读
