怎么样自己开网站,安康市有没有滴滴平台,文安做网站shijuewang,网站开发用户需求分析Mysql半同步复制技术在高性能的数据管理中被广泛采用#xff0c;但它在可靠性方面却存在不足.本文对半同步复制技术进行优化#xff0c;提出了一种快速全同步复制技术#xff0c;通过对半同步数据复制过程中的事务流程设置、线程资源合理应用、批量日志应用等技术手段#… Mysql半同步复制技术在高性能的数据管理中被广泛采用但它在可靠性方面却存在不足.本文对半同步复制技术进行优化提出了一种快速全同步复制技术通过对半同步数据复制过程中的事务流程设置、线程资源合理应用、批量日志应用等技术手段在保证数据可靠性的基础上降低复制过程中的性能损失实现了快速的全同步复制.测试结果表明快速全同步复制技术可以在性能、可靠性和一致性方面做到很好的均衡有效提高了Mysql存储集群的业务承载能力. 目录
1 引言
1 快速全同步复制技术原理
1.1 快速全同步复制
1.2 快速全同步复制的特点
1.2.1 线程复用
1.2.2 数据可靠性保证
1.2.3 批量写入 1 引言
数据复制是将主机节点服务器上的数据及其变更应用到一个或多个备机节点服务器里达到主机节点和备机节点数据相同的目的.复制功能是实现数据库系统高可用性、可扩展性、灾难恢复能力、备份等功能的基础在分布式数据库多副本读写、读写分离、备份容灾等场景应用非常广泛 . 根据复制技术的发生时机及复制后果Mysql复制技术可分为异步复制、同步复制、半同步复制三种.
异步复制是Mysql 原生支持的复制技术主机节点将事务信息写入Binlog文件中时主机节点会通过 Binlog dump 线程给备机节点发送这些新的Binlog变化并不等待从库的响应继而提交事务并写入Binlog所以异步复制不能保证这些事务变化的Binlog数据可靠传输并应用到任何备机节点从而有数据丢失的可能性.
在 2010 年发布的 Mysql 5.5 版本中引入了半同步复制半同步复制解决了异步复制存在的数据可靠性问题主机节点需要等待至少一个备机节点收到且成功把日志写入Relay log文件客户端才可收到复制完成的确认消息从而进入事务的下一个阶段 . 与异步复制相比半同步复制在提交成功返回时已知数据至少存在于两个位置从而提高了数据完整性.
但半同步复制依然存在数据丢失的可能性在半同步复制中如果出现异常在没有任何从库反馈确认消息的情况下会导致事务等待超时这种情况下主库将退化为异步复制直到至少有一个半同步从库恢复正常后主库才恢复半同步复制.为 提 高 数 据 的 可 靠 性 在 2016 年 发 布 的Mysql 5.7.17版本中引入了一个全新的技术称之为InnoDB Group Replication也就是全同步复制.在全同步复制中当主库执行完一个事务必须等所有的从库都执行了该事务才返回给客户端这样就可以完全保证数据在所有节点都被成功复制.但因需等待所有从库执行完该事务才能返回全同步复制的主机节点完成一个事务的时间会被拉长导致性能急剧降低.
1 快速全同步复制技术原理
1.1 快速全同步复制
快速全同步复制是Mysql存储集群主机节点和备机节点通过Binlog进行复制的一种技术通过数据复制期间线程资源的重复利用及批量确认等优化手段在保证主机节点变更日志已经传输到备机节点的基础上快速响应数据库客户的请求和响应 . 快速全同步复制技术的架构如图 1 所示具体运行步骤如下 第一步主机节点Master接收到客户程序的提交请求在完成本地提交后将数据变更日志通过 Binlog Dump 线程发往备机节点Slave此时并不给客户程序反馈请求操作成功的消息.
第二步备机节点接收到 n 个 Binlog 变更日志后IO 线程将变更日志写入备机节点的 Relay Log完成后将写入成功的确认消息ACK发回到主机节点的ACK 消息队列ACK Wait Queue线程池.
第三步主机节点的Wait线程池收到备机节点的确认消息后反馈给客户程序本次请求的处理结束.
1.2 快速全同步复制的特点
Mysql半同步复制5.6版本和5.7版本的基本原理如图2所示. Mysql5.6 的半同步是after commit机制的复制用户事务在主机节点完成提交之后用户线程直到等到备机节点确认消息ACK后才反馈给客户程序事务成功 .Mysql5.7 及以后的增强半同步是 aftersync 的复制机制用户事务在主机节点提交完成之前用户线程直到等到备机节点确认消息ACK后才完成提交并反馈给客户程序事务成功.这两种不同机制的差别导致了主机节点上不同事务间数据一致性的差别在性能上和可靠性上没有根本的改变.
1.2.1 线程复用
无论是 5.6 版本的半同步复制还是 5.7 版本及以后的增强半同步复制在用户会话等待备机节点确认消息Wait ACK期间用户会话始终占用一个线程直到该事务完成才退出 . 在一个负载高的系统大量用户会话在等待 ACK 期间将占用大量的线程资源而影响性能.
而快速全同步复制利用了线程池技术每个事务 Commit包括 DDL、AUTOCOMMIT STMT、COMMIT、XA PREPARE、XA COMMIT 等在完成所有提交过程后将 Wait ACK 数据包发送到客户端之前等待备机节点确认 . 在等待完整 WaitACK时由于使用了线程池事务或其会话不占用任何操作系统线程数据库的工作线程将继续处理来自其他连接的其他请求这种机制避免了资源浪费从而使性能明显得到提升.
1.2.2 数据可靠性保证
在半同步复制中如果数据复制发生异常备机节点不可以用或者数据复制所用的网络发生异常的情况下主机节点会暂停Mysql 默认 10 s 左右对应用的响应复制方式将降为异步复制.直到数据复制恢复正常将恢复为半同步复制 . 当复制方式降为异步复制时数据可靠性就无法保障这在某些业务场景是不允许的.而快速全同步复制在默认情况下是不可以降级为异步复制的只在特殊情况下方可通过参数配置支持降级从而保证数据在任何情况下都不会丢失 . 下面从两个不同场景进行分析当出现异常的情况时快速全同步复制如何处理这种异常.
1.2.3 批量写入
快速全同步复制在性能上的优化还包括批量Relay Log 写入和组提交.批量Relay Log写入是指备机节点可以根据参数配置在接收到一定数量的Binlog 之后才写入 Relay Log然后将 ACK 消息批量反馈到主机节点的应用程序.这在一定程度上提高了备机节点的写入效率并使复制性能得到明显提升.
