关键词：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】异步复制（和MSSQL的高性能模式镜像一样）：
主库只管binlog dump数据到从库，不保证主从完全一致，断电、崩溃等情况会丢失数据。
【2.2】全同步复制：
【2.2.1】核心概念：主从复制，主库要等到从库重做事务并且提交成功，接受到ACK成功确认标识后，主库才能提交事务。
【2.2.2】与半同步的区别：半同步是只需要持久化到relay log阶段即可返回ACK成功标识给主库，而全同步需要等待从库SQL进程完整的运行完该事务内容才能返回ACK成功标识。
【2.2.3】原理：
主库事务写入redo log和 binlog 文件后，binlog dump线程提取binlog数据给IO线程，IO线程把数据加载回从库的relay log文件。
从库SQL线程开启事务重做应用relay log数据操作，等从库提交完后，返回ACK确认标识，主库才会提交。
【2.3】传统半同步复制：
【2.3.1】原理：
master事务commit 指令已经写入redo log（注意，这里已经提交了，再去同步，只是在等一个ACK）和 binlog 文件后，binlog dump线程提取binlog数据给IO线程，IO线程把数据加载回从库的relay log文件。
只要IO线程-》slave的relay log已经flush disk 磁盘落地，slave就返回ACK确认标识给master。
【2.3.2】特性：
这里的commit主库上是已经在 binlog、redo log 中提交了的，其他session都可以看到。
但需要等待从库返回ACK确认标识才会把事务提交到存储引擎持久化（即 ibdata、ibd等磁盘数据文件）且返回到client一个commit成功的指令。
【2.3.3】宕机情况：master上这个事务其实是已经提交了，master的其他Session是可以看到这个提交后的事务的，而slave还没有commit。
这个时候master挂了，master上的数据和slave不一致。master crash后，master根据redo重做提交了这个事务，在切换到从后，slave因为没有commit而回滚了这个事务导致数据丢失。导致主从不一致。
【2.4】增强半同步复制（mysql 5.7及以上才可以用，与MSSQL镜像高安全模式相同）：
与【2.3】传统半同步复制大致一样。唯一的区别就是，在事务提交过来后：
核心区别：主库会等从库在relay log阶段持久化该事务到该文件后，接受ACK成功确认标识后，再进行提交（commit指令写入redo log）
【2.4.1】传统的半同步复制：
master 会把binlog和redo log全部写了。
【2.4.2】增强半同步复制：
master 只会写binlog，然后等slave的IO线程把事务持久化（flush disk）到 relay log 上后，返回ACK确认标识。
master收到确认标识后才会commit 写入到redo log，并返回给客户端commit成功的指令。
【2.4.3】宕机情况：
主库上这个事务因为没有写入redo log，所以这个事务被认为是未提交。master的其他session是不可以看到这个事务的。
这个时候主库挂了，master上的数据和slave一致，master crash后，slave不丢数据。
【2.5】GTID 复制（mysql 在 5.6.2 及之后开始支持GTID）：
原文：https://www.cnblogs.com/gered/p/11299168.html