【MySQL】组复制背景

我会带着你远行 2022-03-15 14:22 160阅读 0赞

> 原文：[https://dev.mysql.com/doc/refman/8.0/en/group-replication-background.html][https_dev.mysql.com_doc_refman_8.0_en_group-replication-background.html]  
> 译者：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.1][18.1]

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

**图18.2 MySQL半同步复制**

![图18.2][18.2]

在上面的两个图片中，可以看到传统异步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组复制协议**

![图18.3][18.3]

最后，组复制是一种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）锁定，因为没有多数可以达成决议。

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

<table> 
 <thead> 
  <tr> 
   <th>组大小</th> 
   <th>多数</th> 
   <th>允许的即时故障数</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>1</td> 
   <td>1</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>2</td> 
   <td>2</td> 
   <td>0</td> 
  </tr> 
  <tr> 
   <td>3</td> 
   <td>2</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>4</td> 
   <td>3</td> 
   <td>1</td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>3</td> 
   <td>2</td> 
  </tr> 
  <tr> 
   <td>6</td> 
   <td>4</td> 
   <td>2</td> 
  </tr> 
  <tr> 
   <td>7</td> 
   <td>4</td> 
   <td>3</td> 
  </tr> 
 </tbody> 
</table>

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

![公众号.jpg][.jpg]

[https_dev.mysql.com_doc_refman_8.0_en_group-replication-background.html]: https://dev.mysql.com/doc/refman/8.0/en/group-replication-background.html
[18.1]: /images/20220315/b5208f2c45744e378aa951cca52cbce2.png
[18.2]: /images/20220315/5af20a041d964df2a7acb7c10a7412f3.png
[18.3]: /images/20220315/59e797f7c697477fa8915b924aece842.png
[.jpg]: /images/20220315/2602fb597f0b40ffaeb613d3981eefbd.png