mysql8.0.19 mgr 参数说明 -m6米乐安卓版下载

本文内容是自我了解和分析相关参数的作用。大致分类6种类型

1. 流控参数
2. 基本参数
3. 选主权重
4. 自动重新加入组
5. 恢复配置
6. ssl部分:这部分不详细介绍

下面逐步介绍，因文字说明比较多，有兴趣的同仁请耐心阅读

流控配置

• 1.group_replication_consistency
  
  eventual：开启该级别的事务（t2），事务执行前不会等待先序事务（t1）的回放完成，也不会影响后序事务等待该事务回放完成
  before：开启了该级别的事务（t2），在开始前首先要等待先序事务（t1）的回放完成，确保此事务将在最新的数据上执行。
  after：开启该级别的事务（t1），只有等该事务回放完成。其他后序事务（t2）才开始执行，这样所有后序事务都会读取包含其更改的数据库状态，而不管它们在哪个成员上执行
  before_and_after：开启该级别等事务（t2），需要等待前序事务的回放完成（t1）；同时后序事务（t3）等待该事务的回放完成
  before_on_primary_failover：在发生切换时，连到新主的事务会被阻塞，等待先序提交的事务回放完成；这样确保在故障切换时客户端都能读取到主服务器上的最新数据，保证了一致性
  eventual 性能最好.

• 2.group_replication_flow_control_mode
  
  该参数用于在线开启和关闭流控，默认为quota，表示开启流控，设置为disabled表示关闭，从该参数也可以看出mgr目前支持基于quota的流控，但也不排除后续增加新的流控机制。只有该参数开启了，剩余9个参数才有可能发挥作用

• 3.group_replication_flow_control_certifier_threshold&group_replication_flow_control_applier_threshold
  
  第一个是认证阶段（certification），在这一阶段，必须mgr集群中的大多数节点认证通过，
  事务才能进入到下一阶段，通过认证的事务会放到一个队列，称之为 certifier queue。

第二个阶段是提交应用阶段（commit-apply），通过认证的事务，在主节点上提交，在applier节点上应用，在applier节点上等待被应用的事务也会放到一个队列中，称之为 replication applier queue。

默认值：
group_replication_flow_control_certifier_threshold = 25000;
group_replication_flow_control_applier_threshold = 25000;
从不同维度来设置触发流控的阈值，前者表示本节点的事务认证队列中积累了多少个待认证的事务才触发节点流控，后者表示事务回放队列积累了多少待认证的事务才触发流控，待执行队列长度超过该值时，flow control被触发。

该值大小的影响需要分场景考虑：
1.如果mgr实例所承受的负载比较稳定:且超过mgr实例的处理能力，则流控机制一直起作用，此时等待认证或等待回放的队列事务个数在所设置的阈值上下小幅波动，波动的幅度跟流控的作用周期相关；

2.如果实例所承受的负载变动很大:低峰时远低于实例处理能力，高峰期时超出实例处理能力。这种情况下，等待认证或回放的事务数也会周期性得剧烈波动，低峰时降为0，高峰时超过所设置的阈值。
那么此时阈值越大，表示流控机制开始起作用的时机越延后。如果各个节点的事务处理能力相同，则大家都积累了足够多的等待处理的事务后触发流控。如果处理能力不同，则仅处理能力最差的节点积累最多的事务。反映到用户层面就是该节点相比其他节点有最大的数据延迟。阈值越大，则延迟也越大.

• 4.group_replication_flow_control_period**

该参数表示多久时间进行一次流控统计，单位为秒，也就是说每隔多少秒节点发送自己的状态信息给其他节点，每个节点收集各节点发送的流控信息，进行统计并计算新一个流控周期的各节点配额。默认和最小的流控周期均为一秒，最小流控周期可设置为60秒，即一分钟。显然，流控的周期越短，流控的精确度越高，性能也更加平滑，虽会增加节点间的网络流量，就目前来看，影响很小。还有一个因素需要考虑的是，在某些业务场景下如果事务提交速度很慢，超过了流控统计周期，则流控可能无法正常发挥作用。此时应该把流控周期调节为大于事务提交速度。

• 5.group_replication_flow_control_member_quota_percent**

该参数可用于为多主模式的mgr实例的各有写操作的节点分配配额。该参数表示为节点分配配额百分比。可设置范围为0~100，如果设置为0，表示采用默认的方式，总配额由所有的写操作节点进行均分。如果单主模式下设置该参数，可能会引起性能损失。节点仅在实例中存在多个写操作节点时才会发挥作用，单主模式下，该参数无效。

• 6.group_replication_flow_control_hold_percent
  
  定义未使用组配额的百分比，以允许流控制下的集群赶上未完成的工作。如果值为0，则表示没有预留任何一部分配额用于处理工作积压。若出现group中某个节点crash重新加入，其加入后必然会跟存活的节点产生较大的数据延迟，若此时外部负载仍然是实例所能承受的最大值，则新加入的节点就无法通过catch up追上其他节点。基于这些的考虑，实际对外提供的配额并不是group最大能力，而是做了部分保留，具体的保留百分比就是通过该参数确定的。默认预留了10%的处理能力，用于有数据延迟的节点追上其他节点。

• 7.group_replication_flow_control_max_commit_quota
  
  定义组的最大流控制配额，或启用流控制期间的任何时间段的最大可用配额。0表示没有最大限额集。不能小于group_replication_flow_control_min_quota和group_replication_flow_control_min_recovery_quota。

• 8.group_replication_flow_control_min_quota
  
  控制可分配给成员的最低流量控制配额，独立于上一阶段执行的计算最小配额。值0表示没有最小限额。不能大于group_replication_flow_control_max_commit_quota。

• 9.group_replication_flow_control_min_recovery_quota**
  
  控制由于组中另一个正在恢复的成员而可以分配给成员的最低限额，独立于上一阶段执行的计算最低限额。值0表示没有最小限额。不能大于group_replication_flow_control_max_commit_quota。
  group_replication_flow_control_min_quota,group_replication_flow_control_min_recovery_quota这两个参数均用于设置一个节点最小能够拥有的配额。但使用场景不同，优先级也不同。若前者非零，则后者无效。前者定义了在任何情况下，该节点所拥有的最小配额。而后者仅定义在group中有其他节点处于故障恢复中时，本节点最小拥有的配额，用于避免新节点加入group后引起已有节点的性能出现太大的下降。

• 10.group_replication_flow_control_release_percent**
  
  定义当流控制不再需要限制写入器成员时，应如何释放组配额，此百分比为每个流控制期间的配额增量。如果值为0，则意味着一旦流控制阈值在限制范围内，就会在单个流控制迭代中释放配额。这个范围允许配额以10倍于当前配额的速度释放，因为这允许更大程度的适应，主要是在流量控制周期较大而配额非常小的情况下。

基础配置

• 11.group_replication_start_on_boot
  
  服务器启动期间是否应该启动组复制。

• 12.group_replication_bootstrap_group
  
  配置此服务器以引导组。此选项只能在一台服务器上设置，并且只能在首次启动组或重新启动整个组时设置。在组引导之后，将这个选项设置为off。它应该被动态地和在配置文件中设置为off。在组运行时使用此选项设置启动两个服务器或重新启动一个服务器可能会导致人工分割大脑的情况，即启动两个具有相同名称的独立组

• 13.group_replication_force_members
  
  比如：
  “198.51.100.44:33061,[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061,example.org:33061”

组通信引擎将检查所提供的ip地址是否为有效格式，并检查是否包含了当前无法访问的任何组成员。否则，将无法验证新配置，因此必须小心地只包含可访问的组成员的在线服务器。列表中任何不正确的值或无效的主机名都可能导致无效配置阻塞组。
在使用group_replication_force_members系统变量成功强制创建新的组成员并解除组阻塞之后，请确保清除系统变量。
在使用group_replication_force_members系统变量成功强制创建新的组成员并解除组阻塞之后，请确保清除系统变量。为了发出start group_replication语句，group_replication_force_members必须为空。

• 14.group_replication_single_primary_mode
  
  指示组自动选择一个服务器作为处理读/写工作负载的服务器。这个服务器是主服务器，其他的都是次服务器。

此系统变量是组范围的配置设置。它必须在所有组成员上具有相同的值，在组复制运行时不能更改它，并且需要完全重新启动组(由服务器使用group_replication_bootstrap_group= on引导)才能使更改生效。从mysql 8.0.16开始，可以使用group_replication_switch_to_single_primary_mode()和group_replication_switch_to_multi_primary_mode() udf在组仍在运行时更改这个系统变量的值

• 15.group_replication_transaction_size_limit
  
  以字节配置复制组接受的最大事务大小。大于此大小的事务由接收成员回滚，不会广播给组。大型事务可能会给复制组带来内存分配方面的问题，这会导致系统速度变慢，或者会导致网络带宽消耗方面的问题，这会导致成员因为忙于处理大型事务而被怀疑失败。

当系统变量设置为0时，组接受的事务大小没有限制。从mysql 8.0开始，这个系统变量的默认设置是150000000字节(大约143 mb)。根据您需要组容忍的最大消息大小调整此系统变量的值，请记住，处理一个事务所需的时间与其大小成正比。group_replication_transaction_size_limit的值在所有组成员上应该是相同的。

• 16.group_replication_exit_state_action
  
  配置服务器实例无意中离开组时的组复制行为，例如遇到applier错误，或者丢失了大多数，或者组中的另一个成员由于怀疑超时而将其驱逐。在失去多数的情况下，成员离开组的超时时间由group_replication_unreachable_majority_timeout系统变量设置，怀疑的超时时间由group_replication_member_expel_timeout系统变量设置。请注意，被开除的组成员直到重新连接到组时才知道自己被开除了，因此，只有在该成员设法重新连接或该成员对自己产生怀疑并将自己开除时，才会采取指定的操作。

当成员驱逐由于超时或失去多数怀疑,如果成员group_replication_autorejoin_tries系统变量设置为指定数量的auto-rejoin尝试,它首先使指定数量的尝试在超级只读模式,然后遵循group_replication_exit_state_action所指定的动作。如果发生applier错误，则不会进行自动重新联接尝试，因为这些错误是不可恢复的。
1.当group_replication_exit_state_action设置为read_only时，如果成员无意中退出了组或耗尽了它的自动重新加入尝试，实例将mysql切换为超级只读模式(通过将系统变量super_read_only设置为on)。read_only退出动作是系统变量引入之前mysql 8.0版本的行为，从mysql 8.0.16开始再次成为默认操作。
2.当group_replication_exit_state_action设置为offline_mode时，如果成员无意中退出了组或耗尽了自动重新加入的尝试，则实例将mysql切换到离线模式(通过将系统变量offline_mode设置为on)。在此模式下，已连接的客户端用户在下一个请求时断开连接，不再接受连接，只有具有connection_admin或超级特权的客户端用户例外。组复制还将系统变量super_read_only设置为on，因此客户机不能进行任何更新，即使它们已经连接了超级特权。offline_mode退出操作在mysql 8.0.18中可用。
3.当group_replication_exit_state_action被设置为abort_server时，如果成员无意中退出了组或耗尽了自动重新加入尝试，则实例将关闭mysql。当系统变量被添加到mysql 8.0.12时，这个设置是默认的，mysql 8.0.15包含了这个设置。

• 17.group_replication_group_name
  mgr集群名称

• 18.group_replication_group_seeds
  可以预定义集群ip端口信息

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

• 19.group_replication_auto_increment_increment
  
  确定在此服务器实例上执行的事务的连续列值之间的间隔。这个系统变量应该对所有组成员具有相同的值。当组复制开始在一个服务器上,服务器系统变量的值auto_increment_increment改为这个值,和服务器系统变量的值auto_increment_offset改变服务器id。这些设置避免重复的选择自动递增的值写在群成员,导致回滚的事务。当组复制停止时，将恢复更改。只有当auto_increment_increment和auto_increment_offset的默认值为1时，才会执行和恢复这些更改。

默认值7表示可用值的数量与允许的复制组最大大小(9个成员)之间的平衡。如果您的组有更多或更少的成员，则可以在开始组复制之前设置此系统变量以匹配预期的组成员数量。在组复制运行时，无法更改设置。

• 20.group_replication_gtid_assignment_block_size
  
  对于多主架构减少校验的复杂度：
  为每个成员保留的连续的gtid的数量。每个成员消耗其块，并在需要时储备更多。
  此系统变量是组范围的配置设置。它必须在所有组成员上具有相同的值，在组复制运行时不能更改它，并且需要完全重新启动组(由服务器使用group_replication_bootstrap_group= on引导)才能使更改生效。
  事务在节点执行完成，commit前发送到gr做校验。校验成功后，gr会给此事务分配一个gtid（如果该事务没有gtid）。gr会给每个节点预留一个范围的gtid，（gtid是由server_uuid 数字组成，gr中gtid中的uuid部分都是一样的，数字部分则为各节点分配一个范围段，用完了再分配一个新的范围段）。这个范围段的大小就是有group_replication_gtid_assignment_block_size变量控制，默认是1000000。这个数字范围如果很大的话，gtid_executed就不能及时合并,许多gtid interval 会使校验算法变得复杂。

• 21.group_replication_ip_whitelist
  指定允许哪些主机连接到组。您为group_replication_local_address中的每个组成员指定的地址必须在复制组中的其他服务器上保留。注意，只有在发出了start group_replication语句并且组通信系统(gcs)可用时，才会验证为该变量指定的值。

• 22.group_replication_local_address
  成员为来自其他成员的连接提供的网络地址，指定为主机:端口格式的字符串。这个地址必须能够被组的所有成员访问，因为组通信引擎使用它进行组复制(xcom, paxos变体)，以便在远程xcom实例之间进行tcp通信。与本地实例的通信通过使用共享内存的输入通道进行
  group_replication_local_address= “[2001:db8:85a3:8d3:1319:8a2e:370:7348]:33061”

• 23.group_replication_message_cache_size
  组复制(xcom)的组通信引擎中可用于消息缓存的最大内存量，它保存作为协商一致协议的一部分在组成员之间交换的消息(及其元数据)。在其他功能中，消息缓存用于恢复那些在一段时间内无法与其他组成员通信后返回组的成员。group_replication_member_expel_timeout系统变量决定允许成员返回组而不是被开除的时间(最多一个小时)。消息缓存的大小应该根据这段时间内预期的消息量来设置，以便它包含所有成员成功返回所需的丢失消息。

• 24.group_replication_poll_spin_loops
  
  组通信线程在等待更多传入网络消息之前等待释放通信引擎互斥锁的次数。

• 25.group_replication_enforce_update_everywhere_checks
  
  启用或禁用多主更新的严格一致性检查。默认是禁用检查。在单主模式下，必须在所有组成员上禁用此选项。在多主模式下，当启用此选项时，将按如下方式检查语句，以确保它们与多主模式兼容:
  如果一个事务是在serializable隔离级别下执行的，那么它在与组同步时提交失败。
  如果事务对具有具有级联约束的外键的表执行，则事务在与组同步时无法提交。

此系统变量是组范围的配置设置。它必须在所有组成员上具有相同的值，在组复制运行时不能更改它，并且需要完全重新启动组(由服务器使用group_replication_bootstrap_group= on引导)才能使更改生效。从mysql 8.0.16开始，可以使用group_replication_switch_to_single_primary_mode()和group_replication_switch_to_multi_primary_mode() udf在组仍在运行时更改这个系统变量的值

• 26.group_replication_compression_threshold
  
  以字节为单位的阈值，超过此值时将对组成员间发送的消息进行压缩。如果该系统变量设置为0，则禁用压缩。group_replication_compression_threshold的值在所有组成员上应该是相同的。

组复制使用lz4压缩算法来压缩在组中发送的消息。注意，lz4压缩算法支持的最大输入大小是2113929216字节。这个限制小于group_replication_compression_threshold系统变量的最大可能值，该值与xcom接受的最大消息大小相匹配。对于lz4压缩算法，不要为group_replication_compression_threshold设置大于2113929216字节的值，因为当启用消息压缩时，无法提交大于这个大小的事务。

• 27.group_replication_components_stop_timeout
  
  以秒为单位，组复制在关闭时等待每个组件。

• 28.group_replication_communication_max_message_size
  
  为组复制通信指定最大消息大小。大于这个大小的消息会自动分割成片段，由接收者分别发送并重新组装。

默认设置最大消息大小为10485760字节(10 mib)，这意味着在mysql 8.0.16版本中默认使用存储残片。最大允许值与slave_max_allowed_packet系统变量的最大值相同，后者是1073741824字节(1 gb)。group_replication_communication_max_message_size的设置必须小于slave_max_allowed_packet的设置，因为应用程序线程不能处理大于slave_max_allowed_packet的消息片段。要关闭存储残片，请为group_replication_communication_max_message_size指定一个零值。group_replication_communication_max_message_size的值在所有组成员上应该是相同的。

为了让复制组的成员使用分段，该组的通信协议版本必须是mysql 8.0.16或以上。使用group_replication_get_communication_protocol() udf查看组的通信协议版本。如果使用较低的版本，则组成员不会将消息分段。可以使用group_replication_set_communication_protocol() udf将组的通信协议设置为更高的版本(如果所有组成员都支持该协议)。

• 29.group_replication_communication_debug_options
  
  配置调试消息的级别，以提供不同的组复制组件，如组通信系统(gcs)和组通信引擎(xcom, paxos变体)。调试信息存储在数据目录中的gcs_debug_trace文件中。

• 30.group_replication_clone_threshold
  
  在分布式恢复过程中，现有成员(捐助方)和连接成员(接收方)之间的事务差异(作为许多事务)触发对连接成员的状态转移使用远程克隆操作。如果连接成员和合适的捐助者之间的事务差距超过阈值，则组复制将通过远程克隆操作（ remote cloning operation）开始分布式恢复。如果事务间隔低于阈值，或者如果远程克隆操作在技术上不可行，则组复制直接从捐献者的二进制日志进行状态传输。

• 31.group_replication_allow_local_lower_version_join
  

允许当前服务器加入组，即使它运行的mysql服务器版本比组低。使用默认设置，如果服务器运行的版本低于现有的组成员，则不允许它们加入复制组。此标准策略确保组中的所有成员都能够交换消息和应用事务。注意，运行mysql 8.0.17或更高版本的成员在检查其兼容性时，会考虑发行版的补丁版本。运行mysql 8.0.16或更低，或mysql 5.7的成员只考虑主版本。
选择主节点权重

• 32.group_replication_member_weight
  可以分配给成员的一个百分比权重，用于在故障转移事件中影响当选为主成员的机会，例如当现有的主成员离开一个单一主成员组时。为成员分配数值权重，以确保选中特定的成员。

自动重新加入组
mysql 8.0.16 版本在mgr插件上增加了一个新的特性，节点自动重新加入组复制功能，简称为auto-rejoin。在某些场景下，比如网络抖动，网络短时间断开，在网络恢复后，无需人为干预，节点自动重新加入组复制，这一特性提升了mysql mgr的容错能力和高可用能力。

先看一个场景，mgr集群，其中有一个节点网络比较糟糕，到其他节点的连接时不时地发生中断，或者其他一些网络连接问题，如丢包等，导致该节点与组内的其他某个节点间的通信中断。如果网络问题持续的时间比较久，超过参数 group_replication_member_expel_timeout 设置的值，组内的其他成员会决定将该节点从组内踢出。当该节点网络恢复之后，它会从组内获取最新的视图，发现它自己已经被踢出，这时就需要人为干预，

另外一个相似的场景，当一个或者多个节点与组内的大多数节点都有网络问题，网络连接中断时间超过 group-replication-unreachable-majority-timeout参数值，这些节点将会从组中退出。当网络恢复后，这些节点也不会自动加入组，同样也需要人为干预才能重新加入组

如何启用auto-rejoin?

通过参数group_replication_autorejoin_tries来启用自动重新加入组复制功能，group_replication_autorejoin_tries 值为0，则表示节点不会进行自动重新加入组复制的操作，如果大于0，比如设置为3，则表示会尝试3次重新加入组复制，每次重试的时间间隔为5分钟。

从以上场景不难看出，在遇到网络问题时，auto-rejoin功能，能够使mgr节点能够在网络恢复后，自动重新加入组复制，而不是需要人为干预，提高了mgr集群的健壮性。

auto-rejoin事件的监控由 performance_schema 来提供，performance_schema 中提供了相关的表记录节点重新加入组复制的一些信息。通过这些表中的信息，我们能知道当前是否正在发生auto-rejoin事件，到目前为止已经发生auto-rejoin重试的次数以及距离下一次重试还有多长时间。这些表总结如下：
1.performance_schema.events_stage_current
2.performance_schema.events_stages_summary_global_by_event_name
3.performance_schema.events_stages_history_long

##查看当前是否正在发生auto-rejoin事件，可以通过下面这个sql来查看：
select count(*) from performance_schema.events_stages_current
where event_name like '%auto-rejoin%';
##查看目前为止已经重试的次数：
select work_completed from performance_schema.events_stages_current where
event_name like '%auto-rejoin%';
##查看距离下一次重试的时间间隔：
select (300.0 - ((timer_wait*10e-12) - 300.0 * num_retries)) as time_remaining from
(select count(*) - 1 as num_retries from
performance_schema.events_stages_current where event_name like '%auto-rejoin%') as t,
performance_schema.events_stages_current where event_name like '%auto-rejoin%';

4.auto-rejoin 与 expel-timeout对比：

mgr中有两种方式能够自动加入组，第一种是auto-rejoin，第二种是通过设置 group-replication-member-expel-timeout参数实现。虽然两种方式能达到同样的效果，但它们的原理并不相同。

expel-timeout方式，节点在组内的状态是 suspected，仍然属于组内，其他节点关于该节点的状态是 unreachable，在这种状态下，不能进行mgr组成员的添加、删除和选主操作，同时expel-timeout不容易被监控。
auto-rejoin方式，节点离开组关系，并且保持super_read_only状态，直到它重新加入组，在重新加入组期间，可能读到过时的数据，auto-rejoin过程更容易被监控。

• 33.group_replication_member_expel_timeout
  组复制组成员在产生怀疑后等待的时间(以秒为单位)，然后将怀疑失败的成员从组中驱逐出去。在怀疑产生之前的最初5秒的检测周期不计入此时间。更改某个组成员上的group_replication_member_expel_timeout的值将立即对该组成员的现有和将来的怀疑生效。并不是强制要求组中的所有成员都具有相同的设置，但是建议这样做，以避免意外的驱逐。

• 34.group_replication_autorejoin_tries
  
  指定如果成员被开除，或者在到达group_replication_unreachable_majority_timeout设置之前无法联系到组中的大多数成员，则该成员自动重新加入组的尝试次数。默认设置0表示成员不尝试重新连接，并继续执行group_replication_exit_state_action系统变量指定的操作。您可以指定2016次尝试的最大次数。

如果您指定了尝试次数，当达到成员被驱逐或无法到达的超时时，它将尝试重新连接(使用当前插件选项值)，然后继续进行进一步的自动重新连接尝试，直到达到指定的尝试次数。在一次失败的自动重新加入尝试之后，成员在下一次尝试之前等待5分钟。在自动重新联接过程中，成员保持超级只读模式，并在其复制组视图上显示错误状态。

• 35.group_replication_unreachable_majority_timeout
  指定受网络分区影响而无法连接到大多数的成员在离开组之前等待的秒数。在一组5个服务器(s1、s2、s3、s4、s5)中，如果(s1、s2)和(s3、s4、s5)之间断开连接，则存在一个网络分区。第一组(s1,s2)现在是少数，因为它不能接触超过一半的组。当大多数组(s3、s4、s5)仍在运行时，少数组将等待指定的时间进行网络重新连接。有关此场景的详细描述。

默认情况下，group_replication_unreachable_majority_timeout设置为0，这意味着由于网络分区而处于少数的成员将永远等待离开该组。如果设置超时，当指定的时间过期时，少数派处理的所有挂起事务将回滚，少数派分区中的服务器将移动到错误状态。如果一个成员将group_replication_autorejoin_tries系统变量设置为指定自动重新联接尝试的次数，那么在超级只读模式下，它将继续执行指定次数的重新联接尝试。如果该成员没有指定任何自动重新连接尝试，或者如果它已经耗尽了指定的尝试次数，则遵循系统变量group_replication_exit_state_action指定的操作。

除了以上还有 ssl相关14参数：

group_replication_recovery_get_public_key
group_replication_recovery_public_key_path
group_replication_recovery_ssl_ca
group_replication_recovery_ssl_capath
group_replication_recovery_ssl_cert
group_replication_recovery_ssl_cipher
group_replication_recovery_ssl_crl
group_replication_recovery_ssl_crlpath
group_replication_recovery_ssl_key
group_replication_recovery_ssl_verify_server_cert
group_replication_recovery_tls_ciphersuites
group_replication_recovery_tls_version
group_replication_recovery_use_ssl
group_replication_ssl_mode
详细内容可参考官方：https://dev.mysql.com/doc/refman/8.0/en/group-replication-options.html

写了这么多，其实流控，节点重新加入和权重，transaction大小，mesage这部分留意一下，其他的建议初期为默认值。