<a href="https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html">https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html</a>
asynchronous 异步复制 fully synchronous 全同步复制 semisynchronous 半同步复制
原理：在异步复制中，master写数据到binlog且sync，slave request binlog后写入relay-log并flush disk 优点：复制的性能最好 缺点：master挂掉后，slave可能会丢失事务 代表：mysql原生的复制
原理：在全同步复制中，master写数据到binlog且sync，所有slave request binlog后写入relay-log并flush disk，并且回放完日志且commit 优点：数据不会丢失 缺点：会阻塞master session，性能太差，非常依赖网络 代表：mysql-cluster
普通的半同步复制
原理: 在半同步复制中，master写数据到binlog且sync，且commit，然后一直等待ack。当至少一个slave request bilog后写入到relay-log并flush disk，就返回ack（不需要回放完日志） 优点：会有数据丢失风险（低） 缺点：会阻塞master session，性能差，非常依赖网络， 代表：after commit, 原生的半同步 重点：由于master是在三段提交的最后commit阶段完成后才等待，所以master的其他session是可以看到这个提交事务的，所以这时候master上的数据和slave不一致，master crash后，slave数据丢失
增强版的半同步复制（lossless replication）
原理: 在半同步复制中，master写数据到binlog且sync，然后一直等待ack. 当至少一个slave request bilog后写入到relay-log并flush disk，就返回ack（不需要回放完日志） 优点：数据零丢失（前提是让其一直是lossless replication），性能好 缺点：会阻塞master session，非常依赖网络 代表：after sync, 原生的半同步 重点：由于master是在三段提交的第二阶段sync binlog完成后才等待, 所以master的其他session是看不见这个提交事务的，所以这时候master上的数据和slave一致，master crash后，slave没有丢失数据
参数
comment
默认值
推荐值
是否动态
rpl_semi_sync_master_wait_for_slave_count
至少有n个slave接收到日志
1
dynamic
rpl_semi_sync_master_wait_point
等待的point
after_sync
rpl_semi_sync_master_timeout
切换复制的timeout
10000（10s）
1000(1s)
rpl_semi_sync_master_enabled
是否开启半同步
off
on
rpl_semi_sync_slave_enabled
如何检验上述after_sync,after_commit 如何检验上述原理的正确性
master上当一个事务waiting for semi-sync ack from slave的时候，后来的事务是在a,b,c哪个阶段卡住呢？
根据以上的测试，可以得知，lossless只卡在b阶段，普通的semi-sync是卡在c阶段。 lossless的性能远远好于普通的semi-sync，即（after_sync 优于 after_commit） 因为lossless 卡在b阶段的时候可以堆积事务，可以在c阶段进行group commit。 普通的semi-sync，卡在c阶段,事务都已经commit了，并没有堆积的过程。
一致性【c】 可用性【a】 分区容忍性【p】 理论：cap 三者不可兼得，必须要牺牲一个
分区，是一定存在的，不是你想不要就不要的。所以，这里只剩下两种组合
cp 牺牲可用性
这种做法，就是保留强一致性，牺牲可用性 案例：可以将rpl_semi_sync_master_timeout设置成一个无限大的值，比如：100天，那么master和slave就强一致了，但是可用性就大打折扣
ap 牺牲一致性
这种做法，就是保留高可用性，牺牲一致性 案例：比如原生的异步复制就是这样咯。可以快速做到切换，但是一致性就没有保障