【MySQL】组复制背景

原文：dev.mysql.com/doc/refman/… 译者：kun 最近在翻译MySQL8.0官方文档 第18章组复制部分，分享出来你们读读，有想加入翻译小队的同窗能够联系我哦。

本节介绍有关MySQL组复制的背景信息。

建立容错系统的最多见方法是建立组件冗余，换句话说，组件能够被移除，而系统应该继续按预期运行。这就形成了一系列的挑战，将这种系统的复杂性提升到一个彻底不一样的水平。具体而言，复制的数据库须要同时维护和管理若干个server成员，而不仅是一个。此外，当多个server协同工做是，系统必须处理其余一些常见的分布式系统问题，诸如断网或脑裂等状况。

所以，最大的挑战是将数据库和数据复制的逻辑与若干个server以简单一致的方式协调运行的逻辑相融合。换句话说，也就是使多个server成员关于系统的状态和系统每次变动的数据保持一致。这能够被归纳为使多个server对于每一个数据库状态转换达成共识，从而使它们都做为一个独立的数据库运行，或者说它们最终达到相同状态。这就意味着它们须要做为（分布式）state machine运行。

MySQL Group Replication提供了一种强大的server间协调机制的分布式state machine复制。组中的server成员会自动地进行协调。在单主模式下，组复制具备自动选主功能，每次只有一个服务器成员接受更新。在多主模式下运行时，全部的服务器成员均可以同时接受更新。这种功能就要求应用程序不得不解决部署所带来的限制。

有一个内置的组成员服务，用于保持组视图的一致性，并在任何给定的时间点对于全部server可用。当Server离开或加入组时，视图会相应地进行更新。server也可能会意外离开组，故障检测机制会自动检测到此状况，并通知组该视图已更改。

对于要提交的事务，决定提交或停止事务是由每一个server单独完成的，但全部组成员必须就该事务在全局事务序列中的顺序达成一致意见。若是存在网络分隔，形成组成员间没法达成协议，则系统在此问题解决前将不会继续运行。所以，组复制还内置了一个自动的脑裂保护机制。

这种机制都是由系统提供的组通讯协议（GCS）提供支持的。该协议保障了故障检测机制，组成员服务的安全和消息的彻底有序传递。该技术的核心是Paxos算法实现的，是组复制中保证数据一致性复制的关键， 它充当了组通讯系统的引擎。

18.1.1 复制技术

在介绍MySQL组复制的详细信息以前，本节将简要介绍一些背景概念以及组复制是如何运行的。经过本节咱们能够了解组复制中须要什么，以及传统异步MySQL复制和组复制之间的区别。

18.1.1.1 主-从复制

传统的MySQL复制提供了一种简单的主–从复制方法。有一个主，以及一个或多个从。主节点执行和提交事务，而后将它们（异步地）发送到从节点，以从新执行（在基于语句的复制中）或应用（在基于行的复制中）。这是一个shared-nothing的系统，默认状况下全部server成员都有一个完整的数据副本。

图18.1 MySQL异步复制

还有一个半同步复制，它在协议中添加了一个同步步骤。这意味着主节点在提交时须要等待从节点确认它已经接收到事务。只有这样，主节点才能继续提交操做。

图18.2 MySQL半同步复制

在上面的两个图片中，能够看到传统异步MySQL复制协议（以及半同步）的图形展现。蓝色箭头表示在不一样server之间或者server与client应用之间的信息交互。

18.1.1.2 组复制

组复制是一种可用于实现容错系统的技术。复制组是一个经过消息传递相互交互的server集群。通讯层提供了原子消息（atomic message）和彻底有序信息交互等保障机制。这些是很是强大的功能，咱们能够据此架构设计更高级的数据库复制解决方案。

MySQL组复制以这些功能和架构为基础，实现了基于复制协议的多主更新。复制组由多个server成员构成，而且组中的每一个server成员能够独立地执行事务。但全部读写（RW）事务只有在冲突检测成功后才会提交。只读（RO）事务不须要在冲突检测，能够当即提交。换句话说，对于任何RW事务，提交操做并非由始发server单向决定的，而是由组来决定是否提交。准确地说，在始发server上，当事务准备好提交时，该server会广播写入值（已改变的行）和对应的写入集（已更新的行的惟一标识符）。而后会为该事务创建一个全局的顺序。最终，这意味着全部server成员以相同的顺序接收同一组事务。所以，全部server成员以相同的顺序应用相同的更改，以确保组内一致。

在不一样server上并发执行的事务可能存在冲突。根据组复制的冲突检测机制，对两个不一样的并发事务的写集合进行检测。如在不一样的server成员执行两个更新同一行的并发事务，则会出现冲突。排在最前面的事务能够在全部server成员上提交，第二个事务在源server上回滚，并在组中的其余server上删除。这就是分布式的先提交当选规则。

图18.3 MySQL组复制协议

最后，组复制是一种share-nothing复制方案，其中每一个server成员都有本身的完整数据副本。

上图描述了MySQL组复制协议，并经过将其与MySQL复制（MySQL半同步复制）进行比较，能够看到一些差别。须要注意的是，这个图片中不包含一些基本共识和Paxos相关的信息。

18.1.2 组复制用例

组复制使您可以根据在一组server中复制系统的状态来建立具备冗余的容错系统。所以，只要它不是所有或多数server发生故障，即便有一些server故障，系统仍然可用，最多只是性能和可伸缩性下降，但它仍然可用。server故障是孤立而且独立的。它们由组成员服务来监控，组成员服务依赖于分布式故障检测系统，其可以在任何server自愿地或因为意外中止而离开组时发出信号。他们是由一个分布式恢复程序来确保当有server加入组时，它们会自动更新组信息到最新。而且多主更新确保了即便在单个服务器故障的状况下也不会阻止更新，没必要进行server故障转移。所以，MySQL组复制保证数据库服务持续可用。

值得注意的一点是，尽管数据库服务可用，但当有一个server崩溃时，链接到它的客户端必须重定向或故障转移到不一样的server。这不是组复制要解决的问题。链接器，负载均衡器，路由器或其余形式的中间件更适合处理这个问题。

总之，MySQL组复制提供了高可用性，高弹性，可靠的MySQL服务。

18.1.2.1 用例场景示例

如下示例是组复制的典型用例。

• 弹性复制 - 须要很是流畅的复制基础架构环境，其中server的数量必须动态增加或收缩，并尽量减小反作用。例如，云数据库服务。

• 高可用分片 -分片是实现写扩展的经常使用方法。使用MySQL组复制实现高可用性分片，其中每一个分片映射到一个复制组。

• 替代主从复制- 在某些状况下，使用单个主服务器会形成单点争用，写入整个组可能更具可扩展性。

• 自动系统 -此外，您能够将MySQL组复制直接部署到已有复制协议的自动化系统中（在本章和前面的章节中已经描述过）。

18.1.3 组复制详细信息

本节介绍有关组复制基础服务的详细信息。

18.1.3.1 故障检测

组复制提供了一种故障检测机制，它可以找到并报告哪些server成员是无响应的，而且假定这些server已死。在更高级别来讲，故障检测是提供关于哪些server可能已死的信息（猜想）的分布式服务。而后，若是组赞成该猜想多是真的，则组断定给定的server确实已经failed。这意味着组中的其他成员进行协调决定以排除给定成员。

某个server无响应时触发猜想， 当server A在给定时间段内没有从server B接收消息时，将会发生超时而且触发猜想。

若是某个server与组的其他成员隔离，则它会怀疑全部其余server都失败了。因为没法与组达成协议（由于它没法确保仲裁成员数），其怀疑不会产生后果。当服务器以此方式与组隔离时，它没法执行任何本地事务。

18.1.3.2 组成员关系

MySQL组复制依赖于组成员服务。这是一个内置的插件。它定义了哪些server在线并在组中。在线server列表一般称为视图。所以，组中的每一个server对于给定时刻积极参与组中的成员具备一致的视图。

同组server不只须要关于事务提交必须达成一致意见，关于当前视图也是。所以，若是同组server赞成新的server加入，则该组自己将被从新配置从而将该server加入其中，并触发视图更新。相反，若是server离开组，不管自愿或被迫的状况，该组都会动态地从新规划其配置，并触发视图更新。

要注意的是，当成员自愿离开时，它首先启动组的动态从新配置。这触发一个过程，其中全部成员必须就不包含已离开server的新视图达成一致。然而，若是成员因为发生意外而离开（例如它意外中止或网络链接断开），则故障检测机制检测到后，将提出该组的从新配置，去除故障成员。如上所述，这须要来自组中大多数服务器达成一致意见。若是组不可以达成一致（例如，当大多数服务器都不在线的状况），则系统不能动态地改变配置，并且系统会锁定以防止脑裂状况的发生。最终，这意味着管理员须要介入并解决这个问题。

18.1.3.3 容错

MySQL组复制构建在Paxos分布式算法实现的基础上，以提供不一样server之间的分布式协调。所以，它须要大多数server处于活动状态以达到仲裁成员数，从而作出决定。这对系统能够容忍的不影响其自身及其总体功能的故障数量有直接影响。容忍f个故障所需的server数量（n）为n = 2×f + 1。

在实践中，这意味着为了容忍一个故障，组必须有三个server。所以，若是一个服务器故障，仍然有两个服务器造成大多数（三分之二）来容许系统自动地继续运行。可是，若是第二个server意外地fail掉，则该组（剩下一个server）锁定，由于没有多数能够达成决议。

如下是说明上述公式的小表。

组大小	多数	容许的即时故障数
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3

下一章将涵盖组复制技术方面的知识。