mysql 异步复制和半同步复制

mysql 异步复制和半同步复制,第1张

在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并且提交这些事务,然后主库线程才能继续做后续 *** 作。这里面有一个很明显的缺点就是,主库完成一个事务的时间被拉长,性能降低。

mysql的主备库通过binlog日志保持一致,主库本地执行完事务,binlog日志落盘后即返回给用户;备库通过拉取主库binlog日志来同步主库的 *** 作。

默认情况下,主库与备库并没有严格的同步,因此存在一定的概率备库与主库的数据是不对等的。

半同步特性的出现,就是为了保证在任何时刻主备数据一致的问题。

相对于异步复制,半同步复制要求执行的每一个事务,都要求至少有一个备库成功接收后,才返回给用户。

实现原理也很简单,主库本地执行完毕后,等待备库的响应消息(包含最新备库接收到的binlog(file,pos)),接收到备库响应消息后,再返回给用户,这样一个事务才算真正完成。

在主库实例上,有一个专门的线程(ack_receiver)接收备库的响应消息,并以通知机制告知主库备库已经接收的日志,可以继续执行。


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/6233568.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-03-18
下一篇 2023-03-18

发表评论

登录后才能评论

评论列表(0条)

保存