快速全同步复制技术通过对半同步数据复制过程中的事务流程设置、线程资源合理应用、批量日志应用等技术手段在保证数据可靠性的基础上降低复制过程中的性能损失实现了快速的全同步复制.测试结果表明快速全同步复制技术可以在性能、可靠性和一致性方面做到很好的均衡有效提高了Mysql存储集群的业务承载能力.

快速全同步复制技术原理

数据复制是将主机节点服务器上的数据及其变更应用到一个或多个备机节点服务器里达到主机节点和备机节点数据相同的目的.复制功能是实现数据库系统高可用性、可扩展性、灾难恢复能力、备份等功能的基础在分布式数据库多副本读写、读写分离、备份容灾等场景应用非常广泛

根据复制技术的发生时机及复制后果Mysql复制技术可分为异步复制、同步复制、半同步复制三种.

原生支持的复制技术主机节点将事务信息写入Binlog文件中时主机节点会通过

Binlog

线程给备机节点发送这些新的Binlog变化并不等待从库的响应继而提交事务并写入Binlog所以异步复制不能保证这些事务变化的Binlog数据可靠传输并应用到任何备机节点从而有数据丢失的可能性.

2010

版本中引入了半同步复制半同步复制解决了异步复制存在的数据可靠性问题主机节点需要等待至少一个备机节点收到且成功把日志写入Relay

log文件客户端才可收到复制完成的确认消息从而进入事务的下一个阶段

与异步复制相比半同步复制在提交成功返回时已知数据至少存在于两个位置从而提高了数据完整性.

但半同步复制依然存在数据丢失的可能性在半同步复制中如果出现异常在没有任何从库反馈确认消息的情况下会导致事务等待超时这种情况下主库将退化为异步复制直到至少有一个半同步从库恢复正常后主库才恢复半同步复制.为

2016

Replication也就是全同步复制.在全同步复制中当主库执行完一个事务必须等所有的从库都执行了该事务才返回给客户端这样就可以完全保证数据在所有节点都被成功复制.但因需等待所有从库执行完该事务才能返回全同步复制的主机节点完成一个事务的时间会被拉长导致性能急剧降低.

快速全同步复制技术原理

快速全同步复制是Mysql存储集群主机节点和备机节点通过Binlog进行复制的一种技术通过数据复制期间线程资源的重复利用及批量确认等优化手段在保证主机节点变更日志已经传输到备机节点的基础上快速响应数据库客户的请求和响应

所示具体运行步骤如下

第一步主机节点Master接收到客户程序的提交请求在完成本地提交后将数据变更日志通过

Binlog

线程发往备机节点Slave此时并不给客户程序反馈请求操作成功的消息.

第二步备机节点接收到

第三步主机节点的Wait线程池收到备机节点的确认消息后反馈给客户程序本次请求的处理结束.

1.2

Mysql半同步复制5.6版本和5.7版本的基本原理如图2所示.

Mysql5.6

commit机制的复制用户事务在主机节点完成提交之后用户线程直到等到备机节点确认消息ACK后才反馈给客户程序事务成功

.Mysql5.7

的复制机制用户事务在主机节点提交完成之前用户线程直到等到备机节点确认消息ACK后才完成提交并反馈给客户程序事务成功.这两种不同机制的差别导致了主机节点上不同事务间数据一致性的差别在性能上和可靠性上没有根本的改变.

1.2.1

版本及以后的增强半同步复制在用户会话等待备机节点确认消息Wait

ACK

WaitACK时由于使用了线程池事务或其会话不占用任何操作系统线程数据库的工作线程将继续处理来自其他连接的其他请求这种机制避免了资源浪费从而使性能明显得到提升.

1.2.2

在半同步复制中如果数据复制发生异常备机节点不可以用或者数据复制所用的网络发生异常的情况下主机节点会暂停Mysql

左右对应用的响应复制方式将降为异步复制.直到数据复制恢复正常将恢复为半同步复制

当复制方式降为异步复制时数据可靠性就无法保障这在某些业务场景是不允许的.而快速全同步复制在默认情况下是不可以降级为异步复制的只在特殊情况下方可通过参数配置支持降级从而保证数据在任何情况下都不会丢失

下面从两个不同场景进行分析当出现异常的情况时快速全同步复制如何处理这种异常.

1.2.3

Log写入是指备机节点可以根据参数配置在接收到一定数量的Binlog

之后才写入

消息批量反馈到主机节点的应用程序.这在一定程度上提高了备机节点的写入效率并使复制性能得到明显提升.