group-replication-background.md

## 18.1 组复制背景


[18.1.1 复制技术](group-replication-replication-technologies.html)

[18.1.2 组复制用例](group-replication-use-cases.html)

[18.1.3 多主模式和单主模式](group-replication-deploying-in-multi-primary-or-single-primary-mode.html)

[18.1.4 组复制服务](group-replication-details.html)

[18.1.5 组复制插件架构](group-replication-plugin-architecture.html)

[](<>)

本节提供有关 MySQL 组复制的背景信息。

创建容错系统的最常见方法是使组件冗余，换句话说，可以删除组件，系统应该继续按预期运行。这带来了一系列挑战，将此类系统的复杂性提高到一个完全不同的水平。具体来说，复制数据库必须处理这样一个事实，即它们需要维护和管理多台服务器，而不仅仅是一台。此外，由于服务器正在合作创建组，因此必须处理其他几个经典的分布式系统问题，例如网络分区或脑裂场景。

因此，最终的挑战是将数据库和数据复制的逻辑与以一致且简单的方式协调多个服务器的逻辑相融合。换句话说，让多台服务器就系统状态和系统所经历的每一次变化的数据达成一致。这可以概括为让服务器在每个数据库状态转换上达成一致，以便它们都作为一个单独的数据库进行，或者它们最终收敛到相同的状态。这意味着它们需要作为（分布式）状态机运行。

MySQL Group Replication 提供分布式状态机复制，并在服务器之间进行强大的协调。当服务器属于同一组时，它们会自动协调自己。该组可以在具有自动主选举的单主模式下运行，其中一次只有一个服务器接受更新。或者，对于更高级的用户，可以在多主模式下部署组，其中所有服务器都可以接受更新，即使它们是同时发布的。这种能力是以应用程序必须绕过此类部署所施加的限制为代价的。

有一个内置的组成员服务，可以使组的视图保持一致，并且在任何给定时间点对所有服务器都可用。服务器可以离开和加入组，视图也会相应更新。有时服务器可能会意外离开组，在这种情况下，故障检测机制会检测到这一点并通知组视图已更改。这都是自动的。

对于要提交的事务，组中的大多数人必须就给定事务在全局事务序列中的顺序达成一致。决定提交或中止事务由每个服务器单独完成，但所有服务器都做出相同的决定。如果存在网络分区，导致成员无法达成一致的分裂，则系统在解决此问题之前不会继续进行。因此，还有一个内置的、自动的、脑裂保护机制。

所有这些都由提供的组通信系统 (GCS) 协议提供支持。它们提供故障检测机制、组成员服务以及安全且完全有序的消息传递。所有这些属性都是创建系统的关键，该系统可确保数据在服务器组中一致地复制。这项技术的核心在于 Paxos 算法的实现。它充当组通信引擎。