同步复制:当主库执行完客户端提交的事务后,需要等到所有从库也都执行完这一事务后,才返回给客户端执行成功。因为要等到所有从库都执行完,执行过程中会被阻塞,等待返回结果,所以性能上会有很严重的影响。一般不使用。
半同步复制:半同步复制模式,可以说是介于异步和同步之间的一种复制模式,主库在执行完客户端提交的事务后,要等待至少一个从库接收到binlog并将数据写入到relay log中才返回给客户端成功结果。半同步复制模式,比异步模式提高了数据的可用性,但是也产生了一定的性能延迟。
半同步复制模式,在一个事务提交成功之后,此事务至少会存在于两个地方一个是主库一个是从库中的某一个。 主要原理是,在master的dump线程去通知从库时,增加了一个ACK机制,也就是会确认从库是否收到事务的标志码,master的dump线程不但要发送binlog到从库,还有负责接收slave的ACK。当出现异常时,Slave没有ACK事务,那么将自动降级为异步复制,直到异常修复后再自动变为半同步复制
半同步复制流程图:
半同步的缺陷:
半同步复制模式也存在一定的数据风险,当事务在主库提交完后等待从库ACK的过程中,如果Master宕机了,这个时候就会有两种情况的问题。
为了解决上面的隐患,MySQL从5.7版本开始,增加了一种新的半同步方式。新的半同步方式的执行过程是将“ Storage Commit ”这一步移动到了“ Write Slave dump ”后面。这样保证了 只有Slave的事务ACK后,才提交主库事务 。MySQL 5.7.2版本新增了一个参数来进行配置: rpl_semi_sync_master_wait_point ,此参数有两个值可配置:
默认参数:
#默认参数 rpl_semi_sync_master_wait_point=AFTER_SYNC #开启增强半同步 rpl_semi_sync_master_wait_for_slave_count=1 #至少有1个从库收到说的就是这个参数。
从5.7版本开始,默认的半同步复制方式就是 AFTER_SYNC 方式了,但是方案不是万能的,因为 AFTER_SYNC 方式是在事务同步到Slave后才提交主库的事务的,若是当主库等待Slave同步成功的过程中Master挂了,这个Master事务提交就失败了,客户端也收到了事务执行失败的结果了,但是Slave上已经将binLog的内容写到Relay Log里了,这个时候,Slave数据就会多了,但是多了数据一般问题不算严重,多了总比少了好。MySQL,在没办法解决分布式数据一致性问题的情况下,它能保证的是完全不丢数据。
区别在于一个在commit之前写relaylog和发送ack
加载插件
主安装: INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; 从安装: INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; #主从也可以都安装 #查看插件是否加载成功 show plugins;
启用半同步
主上: SET GLOBAL rpl_semi_sync_master_enabled = 1; 从上: SET GLOBAL rpl_semi_sync_slave_enabled = 1; #从需要重启io_thread才生效 STOP SLAVE IO_THREAD; START SLAVE IO_THREAD; #检查是否运行 主: show status like 'Rpl_semi_sync_master_status'; 从: show status like 'Rpl_semi_sync_slave_status'; #因为是global变量,所以重启之后失效,可以加入配置文件 #rpl_semi_sync_slave_enabled = 1