Multi-thread Asynchronous Replication MAR强同步复制方案介绍

MAR 强同步复制方案是基于 MySQL 协议的异步多线程强同步复制方案,只有当备机数据完全同步后,才由主机给予应用事务应答,保障数据不丢失。
数据库作为系统数据存储和服务的核心能力,其可用性要求非常高。在生产系统中,通常都需要用高可用方案来保证系统不间断运行,而数据同步技术是数据库高可用方案的基础。MySQL的数据复制默认是异步复制,但异步复制对于核心交易业务场景下,要求数据强一致性是不够的。
Google提供了一个半同步插件,确保必须收到一个备机的应答才让事务在主机中提交,但是当备机应答超时的情况下,半同步复制会由超时时间退化为异步,这在金融场景下风险是比较大的。按照CAP的原理,宁愿牺牲一定的可用性也不愿意把数据丢失,假设备机异常了,退化为异步了,主机继续交易。如果此时主机再发生故障,数据库层面很可能出现数据丢失,一旦数据库层面出现数据丢失,事后要去修复是非常困难的,所以这种时候我们是不让它退化,继续强同步(可能交易失败)。所以在复制这块,我们主要是去解决这两个问题。刚才讲的,而且半同步复制在跨IDC情况下性能也会有问题的。
基于MySQL协议的异步多线程强同步复制方案(Multi-thread Asynchronous Replication 简称MAR),一主两备的高可用,这两个备机是都做强同步复制的,只有当备机数据同步后,才由主机向应用返回事务应答,能够保证数据不丢不错。Percona XtraDB Cluster和MariaDB Galera Cluster在同城跨数据中心的情况下,在MySQL 5.6版本性能损耗非常大,而MySQL5.7版本虽然做了一些异步化处理,但依然会有性能损耗。MAR强同步复制技术的异步化改造,采用与Linux内核处理中断的思路,通过将串行的同步线程并行化,利用线程池和GroupCommit等技术大幅提高性能,大幅度提高性能。在性能方面可以做到同城跨数据中心,5毫秒以内的延迟的情况下,能够保证数据强同步TPS(Transactions Per Second)不会下降。
强同步复制技术原理,如图所示。上半部分:任务执行到写binlog为止,然后将会话保存到session中,接着执行下一轮循环去处理其他请求了,这样就避免让线程阻塞等待应答了;然后MySQL自身负责主备同步的dump线程会将binlog立即发送出去,备机的IO线程收到binlog并写入到relay log之后,再通过UDP给主机一个应答;在主机上,开一组线程来处理应答,收到应答之后找到对应的会话,执行下半部分的commit,send应答,绑定到epoll等操作。绑定到epoll之后这个连接又可以被其他线程检测到并执行了。
Multi-thread Asynchronous Replication MAR强同步复制方案介绍

综合来看,MAR强同步复制的特点保证节点间数据强一致性,又将串行同步线程异步化,引入线程池能力,保证跨IDC情况下TPS不会下降。

猜你喜欢

转载自blog.51cto.com/songlihuan/2481144