MySQL复制一致性问题探索（二）-MGR

最新推荐文章于 2024-04-14 00:14:54 发布

基础技术研究

最新推荐文章于 2024-04-14 00:14:54 发布

阅读量912

点赞数

文章标签： mysql

本文链接：https://blog.csdn.net/TIME_1981/article/details/106099658

版权

本文深入探讨MySQL Group Replication（MGR）如何确保数据一致性，介绍MGR的复制原理、复制过程和事务认证，揭示其通过Paxos协议实现的数据强一致性。MGR解决了传统主从复制的一致性问题，适用于对数据一致性要求高的场景。

摘要由CSDN通过智能技术生成

一、前言

MySQL作为现在很热门的数据库，由于其开源性，在互联网公司受到了很大的青睐，随着对数据库安全可控的考虑，在银行、政府、航空等行业已经开始较大范围的推广和使用，其中如何保证数据一致性是在使用中经常会被问到的问题。

上篇文章分析了MySQL主从复制在特殊场景下会出现数据不一致及如何解决、规避，正是因为基于传统异步复制和半同步复制的缺陷——数据的一致性问题无法保证，MySQL官方在2016年12月第一个GA版本5.7.17正式推出组复制（MySQL Group Replication，简称MGR），本篇文章将详细介绍MGR是如何保证数据一致性的。

二、MGR介绍

组复制是MySQL官方开发的一个开源插件，一个MySQL数据库就是其中一个组员，由MGR做统一的集群管理，解决了原主从模式下故障后需要人工或辅助工具介入的问题，提供了高可用的集群自管理能力。同时它是一种可用于实现容错系统的技术，只要确保多数组员存活就可以继续对外提供服务。最重要的是，它解决了因节点故障或网络问题导致的数据不一致问题，这也是本文讨论的重点，图1是简单的一个拓扑图。

三、MGR复制原理

组复制是一组MySQL Server集群，每个Server都有自己完整的数据副本（shard-nothing复制方案），它们之间数据同步是通过消息进行传递和交互的。相比较主从复制，组复制依然传输Binlog Event，但是并没有采用之前的传输机制，而是创建了独立的通讯通道，通信层提供了原子消息(atomic message)和完全有序信息（total order message）交互、故障检测（脑裂）的保障机制。对比主从简单的点到点、无保证的日志复制传输发生了本质的变化。该技术的核心正是由Paxos算法实现的，它也是实现多主复制的核心技术。这也是为什么组复制能保证数据一致性的关键所在。

在多主模式下，复制组内每个节点都可以独立执行事务，而读写事务需要在组内的其他成员协调之后才可以提交。因此，当一个事务准备提交时，会自动在组内进行原子性的广播，所有节点要么接受，要么不接受事务。组内成员会按照之前发送事务的顺序收到该广播消息（事务），并以同样的顺序重演这些事务日志，最终保证了组内数据完全一致的状态。后文会有详细的事务复制过程讲解。

但是，在不同组成员上并发地执行事务有可能存在资源争用现象。如不同成员并发更新同一行数据。这个时候需要用到组复制另外一个非常重要的功能冲突检测。根据冲突检测判断，按照顺序，第一次提交到所有组成员上的事务继续执行提交（成功），第二次提交到所有成员的事务将被终止（失败），第二次事务在发起原始组成员上执行回滚，在其他组成员将会被删除（丢弃，不会写入到relay log中），后文会有详细的事务认证过程讲解。