组复制官方文档翻译(group replication operations)

Deploying in Multi-Primary or Single-Primary Mode

组复制可以在以下不同模式下运行：

single-primary 模式

multi-primary 模式

默认模式为单主。不可能让组的成员部署在不同的模式，例如一个配置在多主模式，而另一个在单主模式。要在模式之间切换，需要使用不同的配置并重新启动组而不单个成员。无论部署模式如何，组复制不处理客户端故障切换，它必须由应用程序本身，连接器或中间件框架（如代理或路由器）处理。

在多主模式下部署时，将检查语句以确保它们与模式兼容。当在多主模式下部署组复制时，进行以下检查：

1 如果事务在SERIALIZABLE隔离级别下执行，则在将其与组同步时，它的提交将失败。

2 如果事务对具有级联约束的外键执行，则事务在与组同步时无法提交。

可以通过将选项group_replication_enforce_update_everywhere_checks设置为FALSE来禁用这些检查。在单主机模式下部署时，此选项必须设置为FALSE。

 Single-PrimaryMode

在此模式下，组中只有一个一个主节点可设置为读写模式。组中的所有其他成员被设置为只读模式（即，超级只读，也就是超级账户也只能读）。主服务器通常是用于引导组的第一个服务器，所有其他加入的服务器自动识别主服务器并设置为只读。

在单主模式下，将禁用在多主模式下部署的某些检查，因为系统会强制每次只有一个写入程序服务器在组中。例如，允许对具有级联外键的表进行更改，而在多主模式下不允许。在主成员故障时，自动领导者选择机制选择下一个主成员。通过服务器的UUID的字母顺序进行排序，选择列表中的第一个作为新的主节点。

如果主节点从组中删除，则会触发选举，并从组中的其余服务器中选择新的主节点。这个选择通过查看新视图，按照词典顺序排序服务器UUID并选择第一个来执行。一旦选择了新的主节点，它将自动设置为只读，其他辅助节点保留为辅助节点，因此为只读。

在将客户端应用程序重连到新主节点之前，等待新的主节点应用完相关中继日志是一个好习惯。

Multi-Primary Mode

在多主模式下，没有单个主模式的概念。没有必要参与选举程序，因为没有服务器发挥任何特殊的作用。

加入组时，所有服务器都设置为读写模式。

Finding the Primary

以下示例显示了在单主机模式下部署时，如何确定当前哪个服务器是主服务器。

mysql> SELECT VARIABLE_VALUE FROM performance_schema.global_status WHERE VARIABLE_NAME= 'group_replication_primary_member';

+--------------------------------------+

| VARIABLE_VALUE                       |

+--------------------------------------+

| 69e1a3b8-8397-11e6-8e67-bf68cbc061a4 |

+--------------------------------------+

1 row in set (0,00 sec)

Tuning Recovery

每当新成员加入复制组时，它将连接到合适的提供者并提取它所错过的数据，直到它被声明为在线。组复制中的这个关键组件是容错和可配置的。以下部分说明恢复如何工作以及如何调整设置

复制源选择

从群组中的现有在线成员中随机选择一个作为复制源。这样，当多个成员进入组时，基本上可做到不会选择同一个复制源。

如果到所选择的复制源的连接失败，则自动尝试新的连接到新的候选复制源。一旦达到连接重试限制，恢复过程将终止并出现错误。

增强型复制源切换

完整的恢复的另一个主要关注点是确保它能够应对故障。因此，组复制提供了强大的错误检测机制。在早期版本的组复制中，当到达一个复制源时，恢复过程中只能检测由于认证问题或一些其他问题的连接错误。对这种问题情况的反应是切换到新的复制源，因此对不同的成员进行了新的连接尝试。

此行为已扩展为也涵盖其他故障情形：

Purged data scenarios 如果所选择的复制源包含恢复处理所需的一些被清除的数据，则发生错误。恢复检测到此错误并选择新的复制源。

Duplicated data 如果新加成员在恢复期间已经包含与来自选定复制源的数据冲突的某些数据，那么会发生错误。这可能是因为新加成员之前就有一些不当的事务执行引起的。

Other errors如果任何恢复线程失败（接收或applier线程失败），则会出现错误，恢复切换到新的复制源。

有些场景下，一些持续的错误或者甚至短暂的错误，恢复过程会自动重连到原来的复制源或者新的复制源

复制源重连

恢复数据传输依赖于二进制日志和现有的MySQL复制框架，因此一些瞬态错误可能导致接收器或applier线程错误。在这种情况下，复制源切换过程具有重试功能，类似于常规复制中的retries功能。

重试次数

尝试从复制源池连接到其中一个复制源时，joiner所尝试的尝试次数为10.这通过group_replication_recovery_retry_count插件变量配置。以下命令将连接到复制源的最大尝试次数设置为10。

SET GLOBAL group_replication_recovery_retry_count= 10;

重连间隔

group_replication_recovery_reconnect_interval变量定义恢复进程在复制源连接尝试之间应休眠多长时间。此变量的默认设置为60秒，您可以动态更改此值。以下命令将恢复施主连接重试间隔设置为120秒

SET GLOBAL group_replication_recovery_reconnect_interval= 120;

但请注意，恢复不会在每次复制源连接尝试后sleep。在连接器连接到不同的服务器，而不是连续到同一个服务器的情况下，它会假设影响服务器A的问题可能不影响服务器B.因此，当它已经尝试过所有可能的复制源后才会sleep。一旦joiner尝试连接到组中的所有合适的复制源，并且没有剩余，恢复过程将sleep，sleep时间是由group_replication_recovery_reconnect_interval变量配置的秒数。

 

Network Partitioning

当需要复制的变化发生时，组需要实现共识。这是常规事务的情况，但是对于组成员更改和保持组一致的某些内部消息传递也是必需的。共识需要大多数小组成员就给定的决定达成一致。当大多数组成员丢失时，组将无法运行并hang住，因为它无法确保满足大多数原则。

当有多个成员意外故障时，仲裁可能会失效，导致大多数服务器突然从组中删除。例如，在一组5个服务器中，如果其中3个服务器突然没有响应，则大多数服务器受影响，因此不能实现法定人数。事实上，剩下的两个不能分辨其他3个服务器是否崩溃或网络分区是否孤立这2个服务器，因此无法自动重新配置组。

另一方面，如果服务器自愿退出组，则它们指示组应该重新配置自身。在实践中，这意味着一个离开的服务器告诉别人它将要离开。这意味着其他成员可以正确地重新配置组，保持成员资格的一致性，并重新计算多数。例如，在5个服务器的上述情况中，3个一次离开，如果3个离开服务器警告组他们一个接一个地离开，则成员资格能够将自身从5调整到2，并且在同一时间，在发生这种情况时确保法定人数。

 Detecting Partitions

replication_group_members表从此服务器的角度显示当前视图中每个服务器的状态。大多数情况下系统不会陷入网络分区，因此表显示在组中的所有服务器上一致的信息。换句话说，此表上的每个服务器的状态都由当前视图中的所有服务器同意。但是，如果存在网络分区，并且仲裁丢失，则表对于不能联系的那些服务器显示状态UNREACHABLE。此信息由组复制中内置的本地故障检测器导出。

为了理解这种类型的网络分区，下面的部分描述了最初有5个服务器正确工作的情况，以及只有2个服务器在线时该组发生的更改。该场景在图中描述。

因此，假设有一个组中有这5个服务器：

服务器s1，成员标识为199b2df7-4aaf-11e6-bb16-28b2bd168d07

服务器s2，成员标识为199bb88e-4aaf-11e6-babe-28b2bd168d07

服务器s3，成员标识为1999b9fb-4aaf-11e6-bb54-28b2bd168d07

服务器s4，成员标识为19ab72fc-4aaf-11e6-bb51-28b2bd168d07

服务器s5，成员标识为19b33846-4aaf-11e6-ba81-28b2bd168d07

最初该组运行良好，成员之间通信良好。您可以通过登录到s1并查看其replication_group_members表来验证这一点。例如：

mysql> SELECT * FROM performance_schema.replication_group_members;

+---------------------------+--------------------------------------+-------------+-------------+--------------+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+---------------------------+--------------------------------------+-------------+-------------+--------------+

| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | 127.0.0.1   |       13002 | ONLINE       |

| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | 127.0.0.1   |       13001 | ONLINE       |

| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | 127.0.0.1   |       13000 | ONLINE       |

| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | 127.0.0.1   |       13003 | ONLINE       |

| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | 127.0.0.1   |       13004 | ONLINE       |

+---------------------------+--------------------------------------+-------------+-------------+--------------+

5 rows in set (0,00 sec)

但是，稍后有一个灾难性的故障，服务器s3，s4和s5意外停止。几秒钟后，再次查看在s1的replication_group_members表显示它仍然在线，但几个其他成员不是。事实上，如下所示，它们被标记为UNREACHABLE。此外，系统不能重新配置自身以改变成员资格，因为大多数已经丢失。

mysql> SELECT * FROM performance_schema.replication_group_members;

+---------------------------+--------------------------------------+-------------+-------------+--------------+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+---------------------------+--------------------------------------+-------------+-------------+--------------+

| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | 127.0.0.1   |       13002 | UNREACHABLE  |

| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | 127.0.0.1   |       13001 | ONLINE       |

| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | 127.0.0.1   |       13000 | ONLINE       |

| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | 127.0.0.1   |       13003 | UNREACHABLE  |

| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | 127.0.0.1   |       13004 | UNREACHABLE  |

+---------------------------+--------------------------------------+-------------+-------------+--------------+

5 rows in set (0,00 sec)

该表显示，s1现在处于没有外部干预的情况下无法运行的组中，因为大多数服务器不可访问。在这种特殊情况下，组成员资格列表需要重置以允许系统继续进行，这将在本节中解释。或者，您也可以选择停止s1和s2上的组复制（或完全停止s1和s2），找出s3，s4和s5发生的情况和丢失通信的原因，然后重新启动组复制（或服务器）

Unblocking a Partition

组复制使您能够通过强制执行特定配置来重置组成员资格列表。例如，在上面的情况中，其中s1和s2是唯一的在线服务器，您可以选择强制包括仅s1和s2的成员资格配置。这需要检查有关s1和s2的一些信息，然后使用group_replication_force_members变量。

假设你回到组s1和s2是组中唯一剩下的服务器的情况。服务器s3，s4和s5意外离开了组。要使服务器s1和s2继续，您希望强制仅包含s1和s2的成员资格配置。

此过程使用group_replication_force_members并应被视为最后手段补救措施。它必须非常小心地使用，并且仅用于覆盖法定数量的损失。如果被滥用，它可能创建一个人为裂脑情景或完全阻止整个系统。

回想一下，系统被阻塞，并且当前配置如下（由s1上的本地故障检测器察觉到）：

mysql> SELECT * FROM performance_schema.replication_group_members;

+---------------------------+--------------------------------------+-------------+-------------+--------------+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+---------------------------+--------------------------------------+-------------+-------------+--------------+

| group_replication_applier | 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | 127.0.0.1   |       13002 | UNREACHABLE  |

| group_replication_applier | 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | 127.0.0.1   |       13001 | ONLINE       |

| group_replication_applier | 199bb88e-4aaf-11e6-babe-28b2bd168d07 | 127.0.0.1   |       13000 | ONLINE       |

| group_replication_applier | 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | 127.0.0.1   |       13003 | UNREACHABLE  |

| group_replication_applier | 19b33846-4aaf-11e6-ba81-28b2bd168d07 | 127.0.0.1   |       13004 | UNREACHABLE  |

+---------------------------+--------------------------------------+-------------+-------------+--------------+

5 rows in set (0,00 sec)

首先要做的是检查s1和s2的对等地址（组通信标识符）是什么。登录到s1和s2并获取该信息，如下所示。

mysql> SELECT @@group_replication_local_address;

+-----------------------------------+

| @@group_replication_local_address |

+-----------------------------------+

| 127.0.0.1:10000                   |

+-----------------------------------+

1 row in set (0,00 sec)

然后登录到s2并做同样的事操作

mysql> SELECT @@group_replication_local_address;

+-----------------------------------+

| @@group_replication_local_address |

+-----------------------------------+

| 127.0.0.1:10001                   |

+-----------------------------------+

1 row in set (0,00 sec)

一旦知道s1（127.0.0.1:10000）和s2（127.0.0.1:10001）的组通信地址，就可以在两台服务器之一上使用它来注入新的成员资格配置，从而覆盖现有的失去法定人数。在s1上操作：

mysql> SET GLOBAL group_replication_force_members="127.0.0.1:10000,127.0.0.1:10001";

Query OK, 0 rows affected (7,13 sec)

这会通过强制使用不同的配置来撤销组的阻塞情况。检查s1和s2上的replication_group_members以验证此更改后的组成员资格。首先在s1

mysql> select * from performance_schema.replication_group_members;

+---------------------------+--------------------------------------+-------------+-------------+--------------+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+---------------------------+--------------------------------------+-------------+-------------+--------------+

| group_replication_applier | b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | 127.0.0.1   |       13000 | ONLINE       |

| group_replication_applier | b60907e7-4ab6-11e6-afb7-28b2bd168d07 | 127.0.0.1   |       13001 | ONLINE       |

+---------------------------+--------------------------------------+-------------+-------------+--------------+

2 rows in set (0,00 sec)

接着咋s2执行

mysql> select * from performance_schema.replication_group_members;

+---------------------------+--------------------------------------+-------------+-------------+--------------+

| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |

+---------------------------+--------------------------------------+-------------+-------------+--------------+

| group_replication_applier | b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | 127.0.0.1   |       13000 | ONLINE       |

| group_replication_applier | b60907e7-4ab6-11e6-afb7-28b2bd168d07 | 127.0.0.1   |       13001 | ONLINE       |

+---------------------------+--------------------------------------+-------------+-------------+--------------+

2 rows in set (0,00 sec)

当强制一个新的成员资格配置时，确保任何服务器将被强制从组中被确实停止。在上面描述的情形中，如果s3，s4和s5不是真正不可达的，而是在线，则它们可能已经形成了它们自己的功能分区（它们是5的3，因此它们具有多数）。在这种情况下，强制具有s1和s2的组成员列表可以创建人为裂脑情况。因此，在强制新的成员资格配置之前，确保要排除的服务器确实关闭，并且如果不是，则在关闭之前关闭它们是很重要的。