MySQL8 中文参考（八十二）（7）

MySQL8 中文参考（八十二）（6）https://developer.aliyun.com/article/1565906

• 此系统变量用于强制应用新的组成员。在  Group Replication  运行时，可以更改此系统变量的值，并立即生效。您只需要在要保留在组中的一个组成员上设置系统变量的值。有关可能需要强制应用新的组成员的情况以及在使用此系统变量时要遵循的程序的详细信息，请参见第  20.7.8 节，“处理网络分区和失去法定人数”。
  group_replication_force_members指定一组对等地址，以逗号分隔的列表形式，例如host1:port1，host2:port2。未包含在列表中的任何现有成员将不会接收到组的新视图，并将被阻止。对于每个要继续作为成员的现有成员，您必须包括 IP 地址或主机名以及端口，就像在group_replication_local_address系统变量中为每个成员给出的那样。IPv6 地址必须用方括号指定。例如：

"198.51.100.44:33061,[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061,example.org:33061"

• Group Replication 的组通信引擎（XCom）检查提供的  IP  地址是否具有有效格式，并检查您是否包含了当前无法访问的任何组成员。否则，新配置将不被验证，因此您必须小心地只包括在线可访问的组成员。列表中的任何不正确值或无效主机名都可能导致组被阻止，出现无效配置。
  在强制应用新的成员配置之前，确保要排除的服务器已关闭是很重要的。如果没有关闭，请在继续之前将它们关闭。仍然在线的组成员可以自动形成新的配置，如果已经发生了这种情况，强制进一步的新配置可能会为组创建人为的脑裂情况。
  在使用group_replication_force_members系统变量成功强制应用新的组成员并解除组阻塞后，请确保清除该系统变量。为了发出START GROUP_REPLICATION语句，group_replication_force_members必须为空。
• group_replication_group_name

• 此系统变量的值在 Group Replication 运行时无法更改。
  group_replication_group_name 指定了此服务器实例所属的组的名称，必须是有效的 UUID。这个 UUID 是 GTID 的一部分，当组成员从客户端接收到事务，以及组成员内部生成的视图更改事件被写入二进制日志时使用。
  重要提示
  必须使用唯一的 UUID。
• group_replication_group_seeds

• 此系统变量的值可以在 Group Replication 运行时更改，但更改只有在您停止并重新启动组成员的 Group Replication 后才会生效。
  group_replication_group_seeds 是一个组成员的列表，加入的成员可以连接到这些组成员以获取所有当前组成员的详细信息。加入的成员使用这些详细信息来选择并连接到一个组成员，以获取与组的同步所需的数据。该列表包含每个包含的种子成员的单个内部网络地址或主机名，如在种子成员的 group_replication_local_address 系统变量中配置的那样（而不是种子成员的 SQL 客户端连接，如 MySQL Server 的 hostname 和 port 系统变量所指定的）。种子成员的地址被指定为逗号分隔的列表，例如 host1:port1,host2:port2。IPv6 地址必须用方括号指定。例如：

group_replication_group_seeds= "198.51.100.44:33061,[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061, example.org:33061"

• 请注意，您为此变量指定的值在发出 START GROUP_REPLICATION 语句并且 Group Communication System (GCS) 可用之前不会被验证。
  通常，此列表包含组的所有成员，但您可以选择一组成员的子集作为种子。列表必须至少包含一个有效成员地址。在启动 Group Replication 时，每个地址都会被验证。如果列表不包含任何有效成员地址，则发出START GROUP_REPLICATION将失败。
  当服务器加入复制组时，它会尝试连接到其group_replication_group_seeds系统变量中列出的第一个种子成员。如果连接被拒绝，加入成员会尝试按顺序连接列表中的其他种子成员。如果加入成员连接到一个种子成员，但由于某种原因未被添加到复制组（例如，因为种子成员没有在其允许列表中包含加入成员的地址并关闭了连接），则加入成员会继续按顺序尝试剩余的种子成员。
  加入成员必须使用与种子成员在group_replication_group_seeds选项中广告的协议（IPv4  或 IPv6）与种子成员进行通信。对于 Group Replication 的 IP 地址权限，种子成员的允许列表必须包含加入成员的 IP  地址，以便与种子成员提供的协议匹配，或者解析为该协议的地址的主机名。如果加入成员的协议与种子成员广告的协议不匹配，则必须设置并允许此地址或主机名，除了加入成员的group_replication_local_address。如果加入成员没有适当协议的允许地址，则其连接尝试将被拒绝。有关更多信息，请参见第 20.6.4 节，“Group Replication IP 地址权限”。
• group_replication_gtid_assignment_block_size

• 注意
  这个系统变量是一个群组范围的配置设置，需要对复制组进行完全重启才能使更改生效。
  group_replication_gtid_assignment_block_size 指定为每个组成员保留的连续 GTID 数。每个成员消耗自己的块，并在需要时保留更多。
  这个系统变量是一个群组范围的配置设置。在所有群组成员上必须具有相同的值，不能在 Group Replication 运行时更改，并且需要对群组进行完全重启（由具有 group_replication_bootstrap_group=ON 的服务器引导）才能使值更改生效。有关在已执行和认证事务的情况下安全引导群组的说明，请参见 第 20.5.2 节，“重新启动群组”。
  如果群组为此系统变量设置了一个值，并且加入成员为该系统变量设置了不同的值，则加入成员无法加入群组，直到将值更改为匹配。如果群组成员为此系统变量设置了一个值，而加入成员不支持该系统变量，则无法加入群组。
• group_replication_ip_allowlist

• group_replication_ip_allowlist 在 MySQL 8.0.22 中可用，用于替换 group_replication_ip_whitelist。从 MySQL 8.0.24 开始，可以在 Group Replication 运行时更改此系统变量的值，并且更改立即在成员上生效。group_replication_ip_allowlist指定哪些主机被允许连接到组。当 XCom 通信堆栈用于组时（group_replication_communication_stack=XCOM），白名单用于控制对组的访问。当 MySQL 通信堆栈用于组时（group_replication_communication_stack=MYSQL），用户认证用于控制对组的访问，白名单不会被使用，如果设置了则会被忽略。您在group_replication_local_address中为每个组成员指定的地址必须在复制组中的其他服务器上得到允许。请注意，直到发出START GROUP_REPLICATION语句并且组通信系统（GCS）可用之前，您为此变量指定的值不会被验证。默认情况下，此系统变量设置为AUTOMATIC，允许来自主机上活动的私有子网的连接。组复制的组通信引擎（XCom）会自动扫描主机上的活动接口，并识别具有私有子网地址的接口。这些地址以及 IPv4 和（从 MySQL 8.0.14 开始）IPv6 的localhost IP 地址用于创建组复制白名单。有关自动允许地址的范围列表，请参见 Section 20.6.4, “Group Replication IP Address Permissions”。自动私有地址白名单不能用于来自私有网络之外的服务器的连接。对于位于不同机器上的服务器实例之间的组复制连接，您必须提供公共 IP 地址并将其指定为显式白名单。如果为白名单指定了任何条目，则私有地址不会自动添加，因此如果使用其中任何一个，必须明确指定。localhost IP 地址会自动添加。作为group_replication_ip_allowlist选项的值，您可以指定以下任意组合：

• IPv4 地址（例如，198.51.100.44）
  
• 具有 CIDR 表示法的 IPv4 地址（例如，192.0.2.21/24）
  
• IPv6 地址，从 MySQL 8.0.14 开始（例如，2001:db8:85a3:8d3:1319:8a2e:370:7348）
  
• 具有 CIDR 表示法的 IPv6 地址，从 MySQL 8.0.14 开始（例如，2001:db8:85a3:8d3::/64）
  
• 主机名（例如，example.org）
  
• 具有 CIDR 表示法的主机名（例如，www.example.com/24)
  

• 在  MySQL 8.0.14 之前，主机名只能解析为 IPv4 地址。从 MySQL 8.0.14 开始，主机名可以解析为 IPv4  地址、IPv6 地址或两者都有。如果主机名解析为 IPv4 和 IPv6 地址，始终使用 IPv4 地址进行组复制连接。您可以结合主机名或 IP  地址使用 CIDR 表示法来允许具有特定网络前缀的 IP 地址块，但确保指定子网中的所有 IP 地址都在您的控制之下。
  每个允许列表中的条目之间必须用逗号分隔。例如：

"192.0.2.21/24,198.51.100.44,203.0.113.0/24,2001:db8:85a3:8d3:1319:8a2e:370:7348,example.org,www.example.com/24"

• 如果组的任何种子成员在加入成员具有 IPv4 group_replication_local_address时列出了带有 IPv6 地址的group_replication_group_seeds选项，或反之亦然，则还必须设置和允许加入成员的另一地址，以供种子成员提供的协议使用（或解析为该协议的地址的主机名）。有关更多信息，请参见第 20.6.4 节，“组复制 IP 地址权限”。
  可以根据您的安全需求在不同的组成员上配置不同的允许列表，例如，为了保持不同的子网分开。然而，当重新配置组时可能会导致问题。如果没有特定的安全要求要求做出其他安排，请在组的所有成员上使用相同的允许列表。有关更多详细信息，请参见第  20.6.4 节，“组复制 IP 地址权限”。
  对于主机名，只有在另一个服务器发出连接请求时才会进行名称解析。无法解析的主机名不会被视为允许列表验证的一部分，并且会向错误日志中写入警告消息。对已解析的主机名执行前向确认反向 DNS（FCrDNS）验证。
  警告
  主机名在允许列表中比  IP 地址不安全。FCrDNS  验证提供了很好的保护级别，但可能会受到某些类型攻击的影响。仅在绝对必要时在允许列表中指定主机名，并确保所有用于名称解析的组件，如 DNS  服务器，都在您的控制之下。您还可以使用 hosts 文件在本地实现名称解析，以避免使用外部组件。
• group_replication_ip_whitelist

• 从 MySQL 8.0.22 开始，group_replication_ip_whitelist已被弃用，而group_replication_ip_allowlist可用来替代它。对于这两个系统变量，默认值均为AUTOMATIC。
  在群组复制启动时，如果其中一个系统变量已设置为用户定义的值而另一个没有，则使用更改后的值。如果两个系统变量都已设置为用户定义的值，则使用group_replication_ip_allowlist的值。
  如果在群组复制运行时更改group_replication_ip_whitelist或group_replication_ip_allowlist的值，这在 MySQL 8.0.24 中是可能的，那么两个变量都不会优先于另一个。
  新的系统变量与旧的系统变量的工作方式相同，只是术语发生了变化。对于group_replication_ip_allowlist给出的行为描述适用于旧系统变量和新系统变量。
• group_replication_local_address
  此系统变量的值可以在群组复制运行时更改，但更改只在停止并重新启动群组成员的情况下生效。
  group_replication_local_address 设置了成员为其他成员提供连接的网络地址，格式为host:port。这个地址必须被组内所有成员访问，因为它被组通信引擎用于 Group Replication（XCom，一种 Paxos 变体）的 TCP 通信。如果您正在使用 MySQL 通信堆栈在成员之间建立组通信连接（group_replication_communication_stack = MYSQL），那么该地址必须是 MySQL Server 监听的 IP 地址和端口之一，由服务器的 bind_address 系统变量指定。
  警告
  不要使用此地址查询或管理成员上的数据库。这不是 SQL 客户端连接的主机和端口。
  您在 group_replication_local_address 中指定的地址或主机名被 Group Replication 用作复制组内组成员的唯一标识符。只要主机名或 IP 地址都不同，就可以为复制组的所有成员使用相同的端口，只要端口都不同，就可以为所有成员使用相同的主机名或 IP 地址。group_replication_local_address 的推荐端口是 33061。请注意，直到发出 START GROUP_REPLICATION 语句并且 Group Communication System (GCS) 可用之前，不会验证此变量的值。
  由 group_replication_local_address 配置的网络地址必须被所有组成员解析。例如，如果每个服务器实例在不同的机器上具有固定的网络地址，您可以使用机器的 IP 地址，例如 10.0.0.1。如果使用主机名，必须使用完全限定的名称，并确保通过 DNS、正确配置的 /etc/hosts 文件或其他名称解析过程解析。从 MySQL 8.0.14 开始，IPv6 地址（或解析为它们的主机名）也可以使用，以及 IPv4 地址。必须在方括号中指定 IPv6 地址，以区分端口号，例如：

group_replication_local_address= "[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061"

• 如果指定为服务器实例的组复制本地地址的主机名同时解析为 IPv4 和  IPv6 地址，则始终使用 IPv4 地址进行组复制连接。有关组复制支持 IPv6 网络以及使用 IPv4 成员和使用 IPv6  成员混合的复制组的更多信息，请参见第 20.5.5 节，“IPv6 和混合 IPv6 和 IPv4 组的支持”。
  如果您正在使用 XCom 通信堆栈在成员之间建立组通信连接（group_replication_communication_stack = XCOM），则在复制组中的其他服务器上必须将您为每个组成员指定的地址添加到group_replication_ip_allowlist（从 MySQL 8.0.22 开始）或group_replication_ip_whitelist（对于  MySQL 8.0.21 及更早版本）系统变量的列表中。当 XCom 通信堆栈用于组时，允许列表用于控制对组的访问。当 MySQL  通信堆栈用于组时，用户身份验证用于控制对组的访问，允许列表不起作用，如果设置则会被忽略。请注意，如果组的任何种子成员在此成员具有 IPv4 group_replication_local_address时列出具有 IPv6 地址，或反之亦然，则还必须设置并允许该成员的所需协议的替代地址（或解析为该协议地址的主机名）。有关更多信息，请参见第 20.6.4 节，“组复制 IP 地址权限”。
• group_replication_member_expel_timeout

• 此系统变量的值可以在 Group Replication 运行时更改，并立即生效。系统变量的当前值在 Group Replication 检查超时时读取。并非所有组成员都必须具有相同的设置，但建议如此以避免意外驱逐。
  group_replication_member_expel_timeout 指定了在创建怀疑后，Group Replication 组成员在将被怀疑失败的成员从组中驱逐之前等待的时间段（以秒为单位）。在创建怀疑之前的初始 5 秒检测期不计入此时间。在 MySQL 8.0.20 及之前的版本中，group_replication_member_expel_timeout 的值默认为 0，意味着没有等待时间，怀疑的成员在 5 秒检测期结束后立即有可能被驱逐。从 MySQL 8.0.21 开始，默认值为 5，意味着怀疑的成员在 5 秒检测期结束后 5 秒内有可能被驱逐。
  在组成员上更改 group_replication_member_expel_timeout 的值会立即对该组成员上现有及未来的怀疑生效。因此，您可以将其用作强制怀疑超时并驱逐怀疑成员以允许更改组配置的方法。有关更多信息，请参见 第 20.7.7.1 节，“驱逐超时”。
  增加group_replication_member_expel_timeout的值可以帮助避免在较慢或不稳定网络上发生不必要的驱逐，或在预期的瞬时网络中断或机器减速情况下。如果可疑成员在疑虑超时之前再次活跃，它会应用所有被其余组成员缓冲的消息，并进入ONLINE状态，无需操作者干预。您可以指定最多 3600 秒（1 小时）的超时值。重要的是要确保 XCom 的消息缓存足够大，以容纳在指定时间段内预期的消息量，再加上初始的 5 秒检测期，否则成员无法重新连接。您可以使用group_replication_message_cache_size系统变量调整缓存大小限制。有关更多信息，请参见第 20.7.6 节，“XCom 缓存管理”。
  如果超时时间已过，可疑成员在疑虑超时后立即有可能被驱逐。如果成员能够恢复通信并接收到一个将其驱逐的视图，并且成员已将group_replication_autorejoin_tries系统变量设置为指定自动重新加入尝试次数，则在超级只读模式下，它会继续进行指定数量的重新加入尝试。如果成员没有指定任何自动重新加入尝试，或者已耗尽指定数量的尝试次数，则会执行由系统变量group_replication_exit_state_action指定的操作。
  有关使用group_replication_member_expel_timeout设置的更多信息，请参见第 20.7.7.1 节，“驱逐超时”。在没有此系统变量的情况下，为避免不必要的驱逐而采取替代缓解策略，请参见第 20.3.2 节，“组复制限制”。
• group_replication_member_weight

• 可以在 Group Replication 运行时更改此系统变量的值，并且更改会立即生效。在发生故障转移情况时，系统变量的当前值会被读取。group_replication_member_weight 指定了可以分配给成员的百分比权重，以影响在故障转移时成员被选为主要成员的机会，例如当现有主要成员离开单一主要组时。为成员分配数字权重以确保特定成员被选中，例如在主要成员的计划维护期间或在故障转移时确保某些硬件优先考虑。对于配置为以下成员的组：

• 成员-1: group_replication_member_weight=30, server_uuid=aaaa
  
• 成员-2: group_replication_member_weight=40, server_uuid=bbbb
  
• 成员-3: group_replication_member_weight=40, server_uuid=cccc
  
• 成员-4: group_replication_member_weight=40, server_uuid=dddd
  

• 在选举新主要成员时，上述成员将按成员-2、成员-3、成员-4和成员-1的顺序排序。这导致在故障转移时选择成员-2作为新的主要成员。有关更多信息，请参见 Section 20.1.3.1, “Single-Primary Mode”。
  
• group_replication_message_cache_size

• 此系统变量应在所有组成员上具有相同的值。在  Group Replication 运行时可以更改此系统变量的值。更改在您停止并重新启动成员上的 Group Replication  后生效。在此过程中，系统变量的值允许在组成员之间有所不同，但在断开连接的情况下，成员可能无法重新连接。
  group_replication_message_cache_size 设置了在 Group Replication（XCom）的组通信引擎中用于消息缓存的最大内存量。XCom  消息缓存保存了作为共识协议的一部分在组成员之间交换的消息（及其元数据）。消息缓存除了其他功能外，还用于在成员在一段时间内无法与其他组成员通信后重新连接到组时恢复丢失的消息。
  group_replication_member_expel_timeout 系统变量确定了等待期限（最长一小时），该期限是在初始 5 秒检测期限之外允许成员返回到组中而不被驱逐的。XCom  消息缓存的大小应该根据预期的消息量设置，以便在此时间段内包含所有成员成功返回所需的所有丢失消息。直到 MySQL 8.0.20 版本，仅有 5  秒的检测期限是默认值，但从 MySQL 8.0.21 版本开始，默认值是在 5 秒检测期限之后等待 5 秒，总共为 10 秒的时间段。
  确保系统上有足够的内存供您选择的缓存大小限制使用，考虑到  MySQL 服务器的其他缓存和对象池的大小。默认设置为 1073741824 字节（1 GB）。最小设置也是 1 GB，直到 MySQL  8.0.20 版本。从 MySQL 8.0.21 开始，最小设置为 134217728 字节（128  MB），这使得可以在内存可用量受限的主机上部署，并且具有良好的网络连接性，以最小化组成员之间瞬时连接丢失的频率和持续时间。请注意，使用 group_replication_message_cache_size 设置的限制仅适用于缓存中存储的数据，缓存结构需要额外的 50 MB 内存。
  缓存大小限制可以在运行时动态增加或减少。如果减少缓存大小限制，XCom  将删除已经决定并传递的最旧条目，直到当前大小低于限制。当从消息缓存中删除可能需要用于恢复的消息，但当前无法访问的成员时，Group  Replication 的组通信系统（GCS）会通过警告消息向您发出警告。有关调整消息缓存大小的更多信息，请参见 Section 20.7.6,  “XCom Cache Management”。
• group_replication_paxos_single_leader

• 注意
  此系统变量是一个群组范围的配置设置，需要完全重新启动复制组才能使更改生效。
  group_replication_paxos_single_leader从 MySQL 8.0.27 开始可用。当群组处于单主模式时，它使群组通信引擎能够与单一共识领导者一起运行。使用默认设置OFF，此行为被禁用，并且在此系统变量可用之前的版本中使用每个群组成员作为领导者的行为。当系统变量设置为ON时，群组通信引擎可以使用单一领导者来推动共识。在单一共识领导者模式下操作可以提高性能和韧性，特别是当群组的某些次要成员当前无法访问时。有关更多信息，请参见 Section 20.7.3, “Single Consensus Leader”。
  为了使群组通信引擎使用单一共识领导者，群组的通信协议版本必须是 MySQL 8.0.27 或更高版本。使用group_replication_get_communication_protocol()函数查看群组的通信协议版本。如果使用较低版本，则群组无法使用此行为。如果所有群组成员都支持，您可以使用group_replication_set_communication_protocol()函数将群组的通信协议设置为更高版本。有关更多信息，请参见 Section 20.5.1.4, “Setting a Group’s Communication Protocol Version”。
  此系统变量是一个群组范围的配置设置。它必须在所有群组成员上具有相同的值，在 Group Replication 运行时无法更改，并且需要对群组进行完全重新启动（由具有group_replication_bootstrap_group=ON的服务器引导）才能使值更改生效。有关在已执行和认证事务的情况下安全引导群组的说明，请参见 Section 20.5.2, “Restarting a Group”。
  如果组为此系统变量设置了一个值，并且加入成员为该系统变量设置了不同的值，则加入成员在值匹配之前无法加入该组。如果组成员为此系统变量设置了一个值，而加入成员不支持该系统变量，则无法加入该组。
  在性能模式表replication_group_communication_information中的字段WRITE_CONSENSUS_SINGLE_LEADER_CAPABLE显示组是否支持使用单个领导者，即使在查询的成员上当前设置为OFF的group_replication_paxos_single_leader。如果组是在设置为ON的group_replication_paxos_single_leader并且其通信协议版本为 MySQL 8.0.27 或更高版本的情况下启动的，则该字段设置为 1。
• group_replication_poll_spin_loops

• 此系统变量的值可以在 Group Replication 运行时更改，但更改只有在您停止并重新启动组成员上的 Group Replication 后才会生效。
  group_replication_poll_spin_loops 指定组通信线程在等待通信引擎互斥锁被释放之前等待更多传入网络消息的次数。
• group_replication_recovery_complete_at

• 当 Group Replication 运行时，可以更改此系统变量的值，但更改只有在停止并重新启动组成员上的 Group Replication 后才会生效。
  group_replication_recovery_complete_at 指定了在从现有成员接收状态传输后处理缓存事务时应用的策略。您可以选择在成员接收并认证了加入组前错过的所有事务后将其标记为在线（TRANSACTIONS_CERTIFIED），或者只有在接收、认证和应用了这些事务后才将其标记为在线（TRANSACTIONS_APPLIED）。
  此变量在 MySQL 8.0.34 中已弃用（TRANSACTIONS_CERTIFIED 也是如此）。预计在将来的 MySQL 版本中将其移除。
• group_replication_recovery_compression_algorithms

• 当 Group Replication 运行时，可以更改此系统变量的值，但更改只有在停止并重新启动组成员上的 Group Replication 后才会生效。
  group_replication_recovery_compression_algorithms 指定了允许用于 Group Replication 分布式恢复连接的压缩算法，用于从捐赠者的二进制日志传输状态。可用的算法与 protocol_compression_algorithms 系统变量相同。有关更多信息，请参见第 6.2.8 节，“连接压缩控制”。
  如果服务器已设置为支持克隆（参见第 20.5.4.2 节，“用于分布式恢复的克隆”），并且在分布式恢复期间使用远程克隆操作，则此设置不适用。对于此状态传输方法，克隆插件的 clone_enable_compression 设置适用。
• group_replication_recovery_get_public_key

• 当 Group Replication 运行时，可以更改此系统变量的值，但更改只在您停止并重新启动组复制时才会生效。
  group_replication_recovery_get_public_key 指定是否从源请求用于 RSA 密钥对密码交换所需的公钥。如果 group_replication_recovery_public_key_path 设置为有效的公钥文件，则优先于 group_replication_recovery_get_public_key。如果您未在 group_replication_recovery 通道上使用 SSL 进行分布式恢复，并且 Group Replication 的复制用户帐户使用 caching_sha2_password 插件进行身份验证（这是 MySQL 8.0 中的默认设置），则此变量适用。有关更多详细信息，请参见 第 20.6.3.1.1 节，“使用 Caching SHA-2 认证插件的复制用户”。
• group_replication_recovery_public_key_path

• 当 Group Replication 运行时，可以更改此系统变量的值，但更改只在您停止并重新启动组复制时才会生效。
  group_replication_recovery_public_key_path 指定包含源端所需的用于 RSA 密钥对密码交换的公钥的副本的文件的路径名。该文件必须采用 PEM 格式。如果设置了 group_replication_recovery_public_key_path 为有效的公钥文件，则它优先于 group_replication_recovery_get_public_key。此变量适用于在分布式恢复过程中未使用 SSL 进行 group_replication_recovery 通道（因此 group_replication_recovery_use_ssl 设置为 OFF），并且用于 Group Replication 的复制用户帐户使用 caching_sha2_password 插件（这是 MySQL 8.0 中的默认设置）或 sha256_password 插件进行身份验证。（对于 sha256_password，只有在使用 OpenSSL 构建 MySQL 时，设置 group_replication_recovery_public_key_path 才适用。）有关更多详细信息，请参阅 第 20.6.3.1.1 节，“使用 Caching SHA-2 认证插件的复制用户”。
• group_replication_recovery_reconnect_interval

• 此系统变量的值可以在 Group Replication 运行时更改，但更改只有在停止并重新启动组成员上的 Group Replication 后才会生效。
  group_replication_recovery_reconnect_interval 指定在分布式恢复过程中当组中找不到合适的提供者时重新连接尝试之间的休眠时间，单位为秒。
• group_replication_recovery_retry_count

• 此系统变量的值可以在 Group Replication 运行时更改，但更改仅在您停止并重新启动组成员上的 Group Replication 后生效。
  group_replication_recovery_retry_count 指定加入的成员在放弃之前尝试连接可用捐赠者的次数。
• group_replication_recovery_ssl_ca

• 此系统变量的值可以在 Group Replication 运行时更改，但更改仅在您停止并重新启动组成员上的 Group Replication 后生效。
  group_replication_recovery_ssl_ca 指定包含用于分布式恢复连接的受信任 SSL 证书颁发机构列表的文件路径。有关配置分布式恢复的 SSL 信息，请参阅 Section  20.6.2, “Securing Group Communication Connections with Secure Socket  Layer (SSL)”")。
  如果此服务器已设置为支持克隆（参见 Section 20.5.4.2, “Cloning for Distributed Recovery”），并且您已将 group_replication_recovery_use_ssl 设置为 ON，Group Replication 将自动配置克隆 SSL 选项 clone_ssl_ca 的设置，以匹配您对 group_replication_recovery_ssl_ca 的设置。
  当 MySQL 通信堆栈用于组时（group_replication_communication_stack = MYSQL，此设置用于组通信连接的 TLS/SSL 配置，以及分布式恢复连接。
• group_replication_recovery_ssl_capath

MySQL8 中文参考（八十二）（8）https://developer.aliyun.com/article/1565909