（5.2）mysql高可用系列——mysql主从复制

　　　　　　只要IO线程-》slave的relay log已经flush disk 磁盘落地，slave就返回ACK确认标识给master。

　　　　　　注意：

　　　　　　　　这里的commit主库上是已经在 binlog、redo log 中提交了的，其他session都可以看到。

　　　　　　　　但需要等待从库返回ACK确认标识才会把事务提交到存储引擎持久化（即 ibdata、ibd等磁盘数据文件）且返回到client一个commit成功的指令。

　　　　　　　　意思就是，master上这个事务其实是已经提交了，master的其他Session是可以看到这个提交后的事务的，而slave还没有commit。

　　　　　　　　这个时候master挂了，master上的数据和slave不一致。master crash后，master根据redo重做提交了这个事务，在切换到从后，slave因为没有commit而回滚了这个事务导致数据丢失。导致主从不一致。

　　【2.4】增强半同步复制（mysql 5.7及以上才可以用）

　　　　　　与【2.3】传统半同步复制大致一样。唯一的区别就是，在事务提交过来后：

　　　　　　核心区别：主库会等从库在relay log阶段持久化该事务到该文件后，接受ACK成功确认标识后，再进行提交（commit指令写入redo log）

　　　　　　　　传统的半同步复制：

　　　　　　　　　　master 会把binlog和redo log全部写了。

　　　　　　　　增强半同步复制：

　　　　　　　　　　master 只会写binlog，然后等slave的IO线程把事务持久化（flush disk）到 relay log 上后，返回ACK确认标识。

　　　　　　　　　　master收到确认标识后才会commit 写入到redo log，并返回给客户端commit成功的指令。

　　　　　　　　宕机情况：

　　　　　　　　　　主库上这个事务因为没有写入redo log，所以这个事务被认为是未提交。master的其他session是不可以看到这个事务的。

　　　　　　　　　　这个时候主库挂了，master上的数据和slave一致，master crash后，slave不丢数据。　　　　　　　　

（5.2）mysql高可用系列——mysql主从复制

标签：span   引擎   ima   记录   回滚   height   blank   事务   mysql