在MySQL5.5之前,MySQL 的复制是异步 *** 作,主库和从库的数据之间存在一定的延迟,这样存在一个隐患:当在主库上写入一个事务并提交成功,而从库尚未得到主库推送的Binlog日志时,主库宕机了,例如主库可能因磁盘损坏、内存故障等造成主库上该事务Binlog丢失,此时从库就可能损失这个事务,从而造成主从不一致。
为了解决这个问题, MySQL5.5引人了半同步复制机制。
在MySQL 5.5之前的异步复制时,主库执行完 Commit提交 *** 作后,在主库写入 Binlog日志后即可成功返回客户端,无需等待Binlog日志传送给从库,如图31-7所示。
而半同步复制时,为了保证主库上的每一个 Binlog 事务都能够被可靠的复制到从库上,主库在每次事务成功提交时,并不及时反馈给前端应用用户,而是等待其中一个从库也接收到 Binlog事务并成功写入中继日志后,主库才返回Commit *** 作成功给客户端。 半同步复制保证了事务成功提交后,至少有两份日志记录 ,一份在主库的 Binlog日志上,另一份在至少一个从库的中继日志Relay Log 上,从而更进一步保证了数据的完整性。半同步复制的大致流程如图31-8所示。
半同步复制模式下,假如在图31-8的步骤1、2、3中的任何一个步骤中主库宕机,则事务并未提交成功,从库上也没有收到事务对应的 Binlog日志,所以主从数据是一致的
假如在步骤4传送 Binlog日志到从库时,从库宕机或者网络故障,导致 Binlog并没有及时地传送到从库上,此时主库上的事务会等待一段时间(时间长短由参数rpl_semi_sync_master_timeout设置的毫秒数决定),如果 Binlog 在这段时间内都无法成功推送到从库上,则 MySQL自动调整复制为异步模式,事务正常返回提交结果给客户端。
半同步复制很大程度上取决于主从库之间的网络情况,往返时延RTT 越小决定了从库的实时性越好。通俗地说,主从库之间网络越快,从库越实时。
半同步模式是作为MySQL5.5的一个插件来实现的,主库和从库使用不同的插件。安装比较简单,在上一小节异步复制的环境上,安装半同步复制插件即可。
1、首先,判断MySQL服务器是否支持动态增加插件:
2、安装插件
3、可以查看到已安装的插件
4、在安装完插件后,半同步复制默认是关闭的,这时需设置参数来开启半同步
主:
从:
以上的启动方式是在命令行 *** 作,也可写在配置文件中。
主:
从:
4、重启从上的IO线程
从:
如果没有重启,则默认还是异步复制,重启后,slave会在master上注册为半同步复制的slave角色。这时候,主的error.log中会打印如下信息:
查看半同步是否在运行
主:
从:
这两个变量常用来监控主从是否运行在半同步复制模式下。至此,MySQL半同步复制搭建完毕~
来做个实验,观察半同步状态参数的变化。
1、在主库上insert一条记录,观察下变化;
Rpl_semi_sync_master_net_waits加1,说明刚才的insert已经发送到从机并且主机还接收到从机的反馈响应;
2、我们将从机mysql停止,再次在主机上进行insert后查看状态
可以看到,主机进行insert阻塞了10秒才返回结果。Rpl_semi_sync_master_status变为OFF,Rpl_semi_sync_master_no_tx加1,说明这条insert没有同步到从机。后面再一次执行了insert立马返回了结果,说明此时已经降级为异步复制;Rpl_semi_sync_master_no_tx也是增加了1;
3、现在恢复启动从机,再次在主机上进行insert后查看状态
Rpl_semi_sync_master_status还是OFF,Rpl_semi_sync_master_no_tx又增加了1。说明从库重启并不会自动恢复为原来的半同步复制,需要手动 *** 作:
主 SET GLOBAL rpl_semi_sync_master_enabled = 1
从 SET GLOBAL rpl_semi_sync_slave_enabled = 1STOP SLAVE IO_THREADSTART SLAVE IO_THREAD
上面是从机重启后的变化,那么主到从之间的网络问题呢,我们可以利用防火墙来模拟。
对于全同步复制,当主库提交事务之后,所有的从库节点必须收到,APPLY并且提交这些事务,然后主库线程才能继续做后续 *** 作。这里面有一个很明显的缺点就是,主库完成一个事务的时间被拉长,性能降低。
通过xtraback新备份并还原的slave节点通过change master to动态添加到集群中后,主库执行SQL时卡住。
登录主库执行 show processlist发现有一行为 Waiting for semi-sync ACK from slave ,马上定位到半同步复制问题。将主库半同步关闭后,SQL执行成功。因需保证数据的一致性,半同步必须要开启,故继续排查原因。
检查主库的半同步复制正常。
然后去从库检查从库的半同步配置。发现从库"rpl_semi_sync_slave_enabled"为"off"状态。
手动 set global rpl_semi_sync_slave_enabled=1 后, show global variables like 'rpl_semi_sync_slave_enabled'显示已经打开。 主库执行命令仍然卡住。
从库半同步配置后需要重启io_thread。配置完从库的半同步不仅要查看variables,也要确认status的状态。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)