同步方式

一、分类

同步大致为异步、半同步、增强版同步、全同步；

二、详情

1.异步复制

MySQL 默认的复制策略，Master处理事务过程中，将其写入Binlog就会通知Dump thread线程处理，然后完成事务的提交，不会关心是否成功发送到任意一个slave中。 

问题：一旦Master 崩溃，发送主从切换将会发送数据不一致性的风险，但相对来讲性能最好。

2.半同步复制

Master处理事务过程中，提交完事务后，必须等至少一个Slave将收到的binlog写入relay log返回ack才能继续执行处理用户的事务。 

相关配置：

rpl_semi_sync_master_wait_point = AFTER_COMMIT

参数意义：什么时间点开始等ack；注意：这里MySQL 5.5并没有这个配置，MySQL5.7 为了解决半同步的问题而设置的

rpl_semi_sync_master_wait_for_slave_count = 1

参数意义：最低必须收到多少个slave的ack

rpl_semi_sync_master_timeout = 100

参数意义：等待ack的超时时间

问题：一旦Ack超时，将退化为异步复制模式，那么异步复制的问题也将发生；性能下降，增多至少一个RTT时间。

数据不一致性问题，因为等待ACK的点是Commit之后，此时Master已经完成数据变更，用户已经可以看到最新数据，当Binlog还未同步到Slave时，发生主从切换，那么此时从库是没有这个最新数据的，用户又看到老数据。

3.增强半同步

增强半同步和半同步不同是等待ACK时间不同。 

rpl_semi_sync_master_wait_point = AFTER_SYNC

半同步和增强半同步配置区别

半同步的问题是因为等待ACK的点是Commit之后，此时Master已经完成数据变更，用户已经可以看到最新数据，当Binlog还未同步到Slave时，发生主从切换，那么此时从库是没有这个最新数据的，用户又看到老数据。增强半同步将等待ACK的点放在提交Commit之前，此时数据还未被提交，外界看不到数据变更，此时如果发送主从切换，新库依然还是老数据，不存在数据不一致的问题。

问题：一旦Ack超时，将退化为异步复制模式，那么异步复制的问题也将发生；性能下降，增多至少一个RTT时间。如果超时时间设置很大，然后因为网络原来长时间收不到ACK，用户提交是被挂起的，可用性收到打击（半同步一样存在）

4.全同步

mysql全同步复制是指，当主库提交事务的binlog后，所有的从库节点必须全部收到事务并且apply并且提交这些内容之后，即io_thread和sql_thread完成所有binlog变化的接受的应用执行，主库的线程才可以继续进行后续操作，但是缺点是，主库完成一个事务的时间会被拉长，性能急剧降低。