多主模式和单主模式

组复制以单主模式或多主模式运行。群组的模式是一个群组范围的配置设置，由group_replication_single_primary_mode系统变量指定，所有成员都必须相同。ON表示单主要模式，这是默认模式，OFF表示多主要模式。不可能以不同的模式部署组中的成员，例如，一个成员配置为多主要模式，而另一个成员处于单主要模式。

group_replication_single_primary_mode组复制运行时，您不能手动更改值。在MySQL 8.0.13中，您可以使用group_replication_switch_to_single_primary_mode()和group_replication_switch_to_multi_primary_mode() UDF在组复制仍在运行时将组从一种模式移至另一种模式。这些UDF管理更改组模式的过程，并确保数据的安全性和一致性。在早期版本中，要更改组的模式，必须停止组复制并更改group_replication_single_primary_mode所有成员上的值。然后对组进行完全重新引导（服务器使用进行引导，group_replication_bootstrap_group=ON以实施对新操作配置的更改）。您不需要重新启动服务器。

无论部署模式如何，组复制都不会处理客户端故障转移。这必须由诸如MySQL Router 8.0的中间件框架，代理，连接器或应用程序本身来处理。

单主模式

在单group_replication_single_primary_mode=ON主服务器模式（）中，该组有一个设置为读写模式的主服务器。组中的所有其他成员都设置为只读模式（带有super-read-only=ON）。主服务器通常是引导该组的第一台服务器。加入该组的所有其他服务器将了解主服务器，并自动设置为只读模式。

在单主模式下，组复制强制只将一台服务器写入组，因此与多主模式相比，一致性检查的严格性可能较低，并且不需要特别小心地处理DDL语句。该选项group_replication_enforce_update_everywhere_checks启用或禁用组的严格一致性检查。在单主要模式下部署或将组更改为单主要模式时，必须将此系统变量设置为OFF。

被指定为主服务器的成员可以通过以下方式进行更改：

如果现有的主数据库自愿或意外离开该组，则会自动选择一个新的主数据库。
您可以使用group_replication_set_as_primary() UDF 任命特定成员作为新的主要成员。
如果您使用group_replication_switch_to_single_primary_mode() UDF将以多主要模式运行的组更改为以单一主要模式运行，则将自动选举一个新的主要对象，或者可以通过用UDF指定新的主要对象来指定新的主要对象。

仅当所有组成员都运行MySQL 8.0.13或更高版本时，才能使用UDF。自动选择新的主服务器或手动指定新的主服务器时，它会自动设置为可读写，而其他组成员将保持为辅助服务器，并因此保持只读状态。“新的初选”显示了此过程。

新的初选

选举或任命新的主要数据库时，可能会积压已应用于旧的主要数据库但尚未在此服务器上应用的更改。在这种情况下，直到新的主数据库赶上旧的主数据库，读写事务可能会导致冲突并回滚，而只读事务可能会导致陈旧的读取。组复制的流控制机制最大程度地减少了快速成员和慢成员之间的差异，如果激活并适当调整了它，则可以减少这种情况的发生。有关流控制的更多信息，请参见“流量控制”。从MySQL 8.0.14开始，您还可以使用group_replication_consistency系统变量，用于配置组的事务一致性级别，以防止出现此问题。该设置BEFORE_ON_PRIMARY_FAILOVER（或任何更高的一致性级别）将新事务保留在新选出的主数据库上，直到应用了积压。有关事务一致性的更多信息，请参见“事务一致性保证”。如果没有为组使用流控制和事务一致性保证，则优良作法是在将新的主应用程序重新路由到该主数据库之前，等待新主数据库应用其复制相关的中继日志。

主要选举算法

自动主要成员选举过程包括每个成员参见组的新视图，排序潜在的新主要成员，并选择最合适的成员。每个成员都按照其MySQL Server版本中的主要选举算法在本地做出自己的决定。由于所有成员都必须做出相同的决定，因此，如果其他组成员正在运行较低版本的MySQL Server，则成员将调整其主要选举算法，从而使其与该组中拥有最低MySQL Server版本的成员具有相同的行为。

成员按顺序选举主要委员时考虑的因素如下：

考虑的第一个因素是哪个或哪些成员运行最低的MySQL Server版本。如果所有组成员都在运行MySQL 8.0.17或更高版本，则首先按其发行版的补丁程序对成员进行排序。如果任何成员运行的是MySQL Server 5.7或MySQL 8.0.16或更低版本，则首先按其发行版的主版本对成员进行排序，并且忽略补丁程序版本。
如果有多个成员正在运行最低的MySQL Server版本，则考虑的第二个因素是每个成员的成员权重，具体由group_replication_member_weight成员上的系统变量指定。如果组中的任何成员正在运行MySQL服务器5.7（该系统变量不可用），则将忽略此因素。
所述group_replication_member_weight系统变量指定在0-100范围内的数。所有成员的默认权重均为50，因此将权重设置为低于该权重以降低其排序，将权重设置为高于该权重以增加其排序。您可以使用此加权功能来优先使用更好的硬件，或确保在计划的主要维护期间将故障转移到特定成员。
如果有多个成员正在运行最低的MySQL Server版本，并且多个成员中有一个具有最高成员权重（或忽略了成员权重），则考虑的第三个因素是每个成员所生成的服务器UUID的词典顺序，由server_uuid系统变量指定。服务器UUID最低的成员被选为主服务器。该因素可作为保证和可预测的决胜局，因此，如果不能由任何重要因素来确定，则所有小组成员均会做出相同的决定。

查找主数据库

要了解以单主服务器模式部署时当前是哪个服务器，请使用表中的MEMBER_ROLE列performance_schema.replication_group_members。例如：

mysql> SELECT MEMBER_HOST, MEMBER_ROLE FROM performance_schema.replication_group_members;
+-------------------------	+-------------	+
| MEMBER_HOST             	| MEMBER_ROLE 	|
+-------------------------	+-------------	+
| remote1.example.com     	| PRIMARY     	|
| remote2.example.com     	| SECONDARY   	|
| remote3.example.com     	| SECONDARY   	|
+-------------------------	+-------------	+

警告
该group_replication_primary_member状态变量已被弃用，并计划在未来的版本中被删除。

或者使用group_replication_primary_member状态变量。

mysql> SHOW STATUS LIKE 'group_replication_primary_member'

多主模式

在多主要模式（group_replication_single_primary_mode=OFF）中，没有成员扮演特殊角色。加入该组时，与其他组成员兼容的任何成员都被设置为读写模式，并且可以处理写事务，即使它们是同时发出的。

如果某个成员停止接受写事务（例如，在服务器崩溃的情况下），则可以将与其连接的客户端重定向或故障转移到处于读写模式的任何其他成员。组复制本身不处理客户端故障转移，因此您需要使用中间件框架（例如MySQL Router 8.0，代理，连接器或应用程序本身）来安排此过程。“客户端故障转移”显示了如果成员离开组，客户端如何重新连接到备用组成员。

客户端故障转移

组复制是最终的一致性系统。这意味着一旦传入流量减慢或停止，所有组成员将具有相同的数据内容。当流量在流动时，可以先在某些成员上对事务进行外部化，特别是在某些成员的写入吞吐量比其他成员少的情况下，这会导致过时的读取。在多主数据库模式下，速度较慢的成员还可能积压过多的事务积压以进行认证和应用，从而导致更大的冲突和认证失败风险。为了限制这些问题，您可以激活和调整组复制的流控制机制，以最大程度地减少快慢成员之间的差异。有关流控制的更多信息，请参见“流量控制”。

从MySQL 8.0.14开始，如果要为组中的每个事务都拥有一个事务一致性保证，则可以使用group_replication_consistency系统变量来做到这一点。您可以选择适合组工作量和数据读取和写入优先级的设置，同时考虑到提高一致性所需的同步对性能的影响。您还可以为单个会话设置系统变量，以保护特别是对并发敏感的事务。有关事务一致性的更多信息，请参见“事务一致性保证”。

处理检查

在多主模式下部署组时，将检查事务以确保它们与该模式兼容。在多主模式下部署组复制时，将进行以下严格的一致性检查：

如果事务在SERIALIZABLE隔离级别下执行，则在与组同步时，其提交将失败。
如果事务是针对具有具有级联约束的外键的表执行的，则在将自身与组同步时，其提交将失败。

检查由group_replication_enforce_update_everywhere_checks系统变量控制。在多主要模式下，通常应将系统变量设置为ON，但是可以选择将系统变量设置为来禁用检查OFF。在单主要模式下部署时，系统变量必须设置为OFF。

数据定义语句

在多主模式下的组复制拓扑中，在执行数据定义语句（通常称为数据定义语言（DDL））时需要格外小心。

MySQL 8.0引入了对原子数据定义语言（DDL）语句的支持，其中完整的DDL语句作为单个原子事务被提交或回滚。但是，原子或其他方式的DDL语句隐式结束当前会话中处于活动状态的所有事务，就好像您COMMIT在执行该语句之前进行了操作一样。这意味着DDL语句不能在另一个事务内，在诸如的事务控制语句内执行，也不能START TRANSACTION ... COMMIT与同一事务内的其他语句组合。

组复制基于乐观复制范例，其中乐观执行语句，并在必要时稍后回滚。每个服务器在执行时都不会首先确保组协议的安全。因此，在多主模式下复制DDL语句时，需要格外小心。如果对同一对象进行模式更改（使用DDL）并更改对象包含的数据（使用DML），则需要通过同一服务器处理更改，而模式操作尚未完成并在各处复制。否则，当操作中断或仅部分完成时，可能导致数据不一致。

有关MySQL 8.0中对原子DDL的支持以及某些语句的复制所引起的行为变化的详细信息，请参见“原子数据定义语句支持”。

版本兼容性

为了获得最佳兼容性和性能，组中的所有成员应运行相同版本的MySQL Server，因此应运行相同版本的组复制。在多主模式下，这更为重要，因为所有成员通常都将以读写模式加入该组。如果组中包含运行多个MySQL Server版本的成员，则某些成员可能与其他成员不兼容，因为它们支持其他成员不具备的功能或缺少其他成员具有的功能。为了防止这种情况，当新成员加入（包括以前已升级并重新启动的成员）时，该成员将对组中的其余成员进行兼容性检查。

这些兼容性检查的结果在多主模式下尤其重要。如果加入成员所运行的MySQL Server版本高于现有组成员所运行的最低版本，则它将加入该组，但保持只读模式。（在以单主要模式运行的组中，无论如何，新添加的成员在任何情况下均默认为只读。）运行MySQL 8.0.17或更高版本的成员在检查兼容性时会考虑该发行版的补丁程序版本。运行MySQL 8.0.16或更低版本或MySQL 5.7的成员仅考虑主要版本。

在具有使用不同MySQL Server版本的成员的多主模式下运行的组中，组复制自动管理运行MySQL 8.0.17或更高版本的成员的读写状态。如果成员离开该组，则运行当前最低版本的成员将自动设置为读写模式。当您将以单主要模式运行的组更改为以多主要模式运行时，请使用group_replication_switch_to_multi_primary_mode() UDF，组复制会自动将成员设置为正确的模式。如果成员运行的MySQL服务器版本高于组中存在的最低版本的成员，则成员将自动置于只读模式，而运行最低版本的成员将处于读写模式。

有关组中版本兼容性及其在升级过程中如何影响组行为的完整信息，请参见“在组中组合不同的成员版本”。