标签：span 引擎 ima 记录 回滚 height blank 事务 mysql
关键词：mysql主从复制，mysql复制
【1】mysql支持的复制类型
基于binlog的3种模式（详情参考：binlog的3种日志记录模式），oracle在mysql5.5版本收购
【1.1】statement：基于语句的复制（5.5.6之前默认），主服务器执行的SQL语句，在从服务器执行同样的语句
【1.2】row：基于行的复制（5.5.7之后默认），把改变的内容复制到从库，而不是把SQL命令在从库重新执行一遍。mysql5.0就开始支持
【1.3】mixed：混合类型的复制，默认是使用 statement 语句方式复制，一旦发现基于语句无法精确复制时（比如now() 因为主从有延迟导致数据不一致）就会采用基于 row 行的方式复制。
【2】mysql的4种同步方式介绍
以下图片均引用自《深入浅出mysql开发、优化与管理维护》
【2.1】异步复制：
主库只管binlog dump数据到从库，不保证主从完全一致，断电、崩溃等情况会丢失数据。（和MSSQL的高性能模式镜像一样）
【2.2】全同步复制：
主库事务写入redo log和 binlog 文件后，binlog dump线程提取binlog数据给IO线程，IO线程把数据加载回从库的relay log文件。
从库SQL线程开启事务重做应用relay log数据操作，等从库提交完后，返回ACK确认标识，主库才会提交。
【2.3】传统半同步复制：
master事务commit 指令已经写入redo log（注意，这里已经提交了，再去同步，只是在等一个ACK）和 binlog 文件后，binlog dump线程提取binlog数据给IO线程，IO线程把数据加载回从库的relay log文件。
只要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不丢数据。
标签：span 引擎 ima 记录 回滚 height blank 事务 mysql
原文地址：https://www.cnblogs.com/gered/p/11299168.html
