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

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

• 在 Group Replication 运行时可以更改此系统变量的值，并立即生效。group_replication_communication_debug_options 配置不同 Group Replication 组件（如 Group Communication System（GCS）和组通信引擎（XCom，一种 Paxos 变体））提供的调试消息级别。调试信息存储在数据目录中的GCS_DEBUG_TRACE文件中。可以组合作为字符串指定的可用选项集。以下选项可用：

• GCS_DEBUG_NONE 禁用 GCS 和 XCom 的所有调试级别。
  
• GCS_DEBUG_BASIC 在 GCS 中启用基本调试信息。
  
• GCS_DEBUG_TRACE 在 GCS 中启用跟踪信息。
  
• XCOM_DEBUG_BASIC 在 XCom 中启用基本调试信息。
  
• XCOM_DEBUG_TRACE 在 XCom 中启用跟��信息。
  
• GCS_DEBUG_ALL 在 GCS 和 XCom 中启用所有调试级别。
  

• 将调试级别设置为GCS_DEBUG_NONE仅在没有任何其他选项的情况下提供时才生效。将调试级别设置为GCS_DEBUG_ALL会覆盖所有其他选项。
  
• group_replication_communication_max_message_size

• 所有组成员应该具有相同的系统变量值。在组复制运行时，无法更改此系统变量的值。您必须停止组复制，更改系统变量的值，然后在每个组成员上重新启动组复制。在此过程中，系统变量的值允许在组成员之间有所不同，但某些组成员上的事务可能会被回滚。
  group_replication_communication_max_message_size指定了组复制通信的最大消息大小。超过此大小的消息会自动分割成片段单独发送，并由接收方重新组装。更多信息，请参见第 20.7.5 节，“消息分段”。
  默认情况下，最大消息大小为 10485760 字节（10 MiB），这意味着在 MySQL 8.0.16 版本中默认使用分段。最大允许值与replica_max_allowed_packet和slave_max_allowed_packet系统变量的最大值相同，即 1073741824 字节（1 GB）。group_replication_communication_max_message_size的设置必须小于replica_max_allowed_packet或slave_max_allowed_packet的设置，因为应用程序线程无法处理大于最大允许数据包大小的消息片段。要关闭分段，请为group_replication_communication_max_message_size指定零值。
  为了使复制组的成员使用分段，组的通信协议版本必须是 MySQL 8.0.16 或更高。使用group_replication_get_communication_protocol()函数查看组的通信协议版本。如果使用较低版本，则组成员不会分段消息。如果所有组成员支持，可以使用group_replication_set_communication_protocol()函数将组的通信协议设置为更高版本。更多信息，请参阅 Section 20.5.1.4, “设置组的通信协议版本”。
• group_replication_communication_stack

• 注意
  这个系统变量实际上是一个整个组的配置设置，更改生效需要对复制组进行完全重启。
  group_replication_communication_stack指定了是使用  XCom 通信栈还是 MySQL 通信栈来建立组成员之间的组通信连接。XCom 通信栈是 Group Replication 自己的实现，在  MySQL 8.0.27 之前的所有版本中始终使用，并且不支持认证或网络命名空间。MySQL 通信栈是 MySQL  服务器的本机实现，支持认证和网络命名空间，并在发布后立即访问新的安全功能。组的所有成员必须使用相同的通信栈。
  当你使用 MySQL 的通信栈代替 XCom 时，MySQL 服务器使用自己的认证和加密协议在组成员之间建立每个连接。
  注意
  如果你正在使用 InnoDB Cluster，group_replication_communication_stack的默认值是MYSQL。
  更多信息，请参阅 MySQL InnoDB Cluster。
  在设置组使用 MySQL 通信堆栈时需要进行额外配置；请参阅 第 20.6.1 节，“连接安全管理的通信堆栈”。
  group_replication_communication_stack 实际上是一个组范围的配置设置，所有组成员必须具有相同的设置。但是，Group Replication 对于组范围配置设置并不执行检查。具有与其余组不同值的成员无法与其他成员通信，因为通信协议不兼容，因此无法交换有关其配置设置的信息。
  这意味着虽然在  Group Replication  运行时可以更改系统变量的值，并在重新启动组成员的情况下生效，但成员仍然无法重新加入组，直到在所有成员上更改了设置。因此，您必须在所有成员上停止  Group Replication 并更改系统变量的值，然后才能重新启动组。由于所有成员都已停止，因此需要对组进行完全重启（由具有 group_replication_bootstrap_group=ON 的服务器引导）以使值更改生效。有关从一种通信堆栈迁移到另一种的说明，请参阅 第 20.6.1 节，“连接安全管理的通信堆栈”。
• group_replication_components_stop_timeout

• 此系统变量的值可以在 Group Replication 运行时更改，但更改只有在您停止并重新启动组成员上的 Group Replication 后才会生效。
  group_replication_components_stop_timeout 指定 Group Replication 在关闭时等待其各个模块完成正在进行的进程的时间，单位为秒。组件超时在发出 STOP GROUP_REPLICATION 语句后应用，该语句在服务器重新启动或自动重新加入时会自动执行。
  超时时间用于解决  Group Replication 组件无法正常停止的情况，这可能发生在成员处于错误状态时被驱逐出组，或者在诸如 MySQL  Enterprise Backup 正在持有成员上的表的全局锁时。在这种情况下，成员无法停止应用程序线程或完成分布式恢复过程以重新加入。STOP GROUP_REPLICATION 不会完成，直到情况得到解决（例如，通过释放锁），或者组件超时到期并且模块无论其状态如何都会被关闭。
  在  MySQL 8.0.27 之前，默认组件超时时间为 31536000 秒，即 365  天。在这种情况下，组件超时对于描述的情况并不起作用，因此建议设置一个较低的值。从 MySQL 8.0.27 开始，默认值为 300  秒，因此如果在此时间之前未解决问题，Group Replication 组件将在 5 分钟后停止，允许成员重新启动并重新加入。
• group_replication_compression_threshold

• 在组成员之间发送的消息超过此阈值字节时应用压缩。如果此系统变量设置为零，则禁用压缩。group_replication_compression_threshold 的值应在所有组成员上保持一致。
  Group Replication 使用 LZ4 压缩算法来压缩组内发送的消息。请注意，LZ4 压缩算法支持的最大输入大小为 2113929216 字节。此限制低于 group_replication_compression_threshold 系统变量的最大可能值，该值与 XCom 接受的最大消息大小相匹配。使用 LZ4 压缩算法时，请不要为 group_replication_compression_threshold 设置大于 2113929216 字节的值，因为启用消息压缩时，超过此大小的事务无法提交。
  更多信息，请参见 第 20.7.4 节，“消息压缩”。
• group_replication_consistency

• 在运行 Group Replication 时可以更改此系统变量的值。group_replication_consistency 是一个服务器系统变量，而不是 Group Replication 插件特定的变量，因此不需要重新启动 Group Replication 才能使更改生效。更改系统变量的会话值会立即生效，更改全局值会影响在更改后启动的新会话。需要 GROUP_REPLICATION_ADMIN 权限才能更改此系统变量的全局设置。group_replication_consistency 控制组提供的事务一致性保证。您可以全局配置一致性，也可以针对每个事务进行配置。group_replication_consistency 还配置了单主组中新选举的主节点使用的围栏机制。必须考虑该变量对只读（RO）和读写（RW）事务的影响。以下列表显示了该变量的可能值，按照事务一致性保证递增的顺序排列：

• EVENTUAL
  在执行之前，RO 和 RW  事务都不会等待前置事务被应用。这是在添加此变量之前 Group Replication 的行为。一个 RW  事务不会等待其他成员应用事务。这意味着一个事务在其他成员之前可能在一个成员上被外部化。这也意味着在主要故障转移发生时，新的主要成员可以在之前的主要事务全部应用之前接受新的  RO 和 RW 事务。RO 事务可能导致过时的值，RW 事务可能由于冲突而导致回滚。
  
• BEFORE_ON_PRIMARY_FAILOVER
  具有新选举的主要成员正在应用来自旧主要成员的积压时，新的  RO 或 RW  事务将被保留（不被应用），直到任何积压都被应用。这确保了主要故障转移发生时，无论是故意还是非故意，客户端始终看到主要成员上的最新值。这保证了一致性，但意味着客户端必须能够处理应用积压时的延迟。通常这种延迟应该是最小的，但取决于积压的大小。
  
• BEFORE
  一个 RW 事务在被应用之前等待所有前置事务完成。一个 RO 事务在执行之前等待所有前置事务完成。这确保了该事务通过仅影响事务的延迟来读取最新值。这减少了每个 RW 事务上同步的开销，通过确保同步仅在 RO 事务上使用。这种一致性级别还包括BEFORE_ON_PRIMARY_FAILOVER提供的一致性保证。
  
• AFTER
  一个  RW 事务等待直到其更改已应用到所有其他成员。这个值对 RO  事务没有影响。这种模式确保了当事务在本地成员上提交时，任何后续事务都会读取任何组成员上写入的值或更近期的值。在主要用于 RO  操作的组中使用此模式，以确保一旦提交，应用的 RW  事务就会在所有地方应用。您的应用程序可以使用此模式确保后续读取获取包含最新写入的最新数据。这减少了每个 RO 事务上同步的开销，通过确保同步仅在  RW 事务上使用。这种一致性级别还包括BEFORE_ON_PRIMARY_FAILOVER提供的一致性保证。
  
• BEFORE_AND_AFTER
  一个 RW 事务等待 1) 所有前置事务完成后才被应用，2) 直到其更改在其他成员上被应用。一个 RO 事务在执行之前等待所有前置事务完成。这种一致性级别还包括BEFORE_ON_PRIMARY_FAILOVER提供的一致性保证。
  

• 有关更多信息，请参见 Section 20.5.3, “事务一致性保证”。
  
• group_replication_enforce_update_everywhere_checks

• 注意这个系统变量是一个群组范围的配置设置，需要对复制组进行完全重启才能使更改生效。group_replication_enforce_update_everywhere_checks 启用或禁用多主更新到处的严格一致性检查。默认情况下，检查是禁用的。在单主模式下，所有群组成员必须禁用此选项。在多主模式下，当启用此选项时，语句将按以下方式进行检查，以确保它们与多主模式兼容：

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

• 这个系统变量是一个群组范围的配置设置。在所有群组成员上必须具有相同的值，在 Group Replication 运行时不能更改，并且需要通过一个具有 group_replication_bootstrap_group=ON 的服务器进行完全重启群组（引导）以使值更改生效。有关在已执行和认证事务的情况下安全引导群组的说明，请参见 Section 20.5.2, “重新启动群组”。
  如果群组为此系统变量设置了一个值，并且加入的成员为该系统变量设置了不同的值，则加入的成员在将值更改为匹配之前无法加入群组。如果群组成员为此系统变量设置了一个值，而加入的成员不支持该系统变量，则无法加入群组。
  从 MySQL 8.0.16 版本开始，您可以使用group_replication_switch_to_single_primary_mode()和group_replication_switch_to_multi_primary_mode()函数在群组仍在运行时更改此系统变量的值。有关更多信息，请参见第 20.5.1.2 节，“更改群组模式”。
  
• group_replication_exit_state_action

• 当 Group Replication 在运行时，可以更改此系统变量的值，并且更改会立即生效。当发生需要该行为的问题时，会读取系统变量的当前值。
  group_replication_exit_state_action 配置了当此服务器实例意外离开群组时 Group Replication 的行为，例如在遇到应用程序错误后，或在丢失多数情况下，或当群组的另一个成员因超时而将其驱逐时。在丢失多数情况下，成员离开群组的超时期由group_replication_unreachable_majority_timeout系统变量设置，而对于怀疑的超时期由group_replication_member_expel_timeout系统变量设置。请注意，被驱逐的群组成员在重新连接到群组之前不知道自己被驱逐，因此只有在成员成功重新连接或成员对自己提出怀疑并驱逐自己时才会执行指定的操作。
  当由于超时的怀疑或多数丢失而将组成员驱逐时，如果成员将group_replication_autorejoin_tries系统变量设置为指定自动重新加入尝试次数，则首先在超级只读模式下进行指定次数的尝试，然后按照group_replication_exit_state_action指定的操作进行。在出现应用程序错误时不会进行自动重新加入尝试，因为这些错误无法恢复。
  当group_replication_exit_state_action设置为READ_ONLY时，如果成员意外退出组或耗尽自动重新加入尝试次数，则实例将将 MySQL 切换到超级只读模式（通过将系统变量super_read_only设置为ON）。READ_ONLY退出操作是在引入系统变量之前的 MySQL 8.0 版本中的行为，并且从 MySQL 8.0.16 开始再次成为默认设置。
  当group_replication_exit_state_action设置为OFFLINE_MODE时，如果成员意外退出组或耗尽自动重新加入尝试次数，则实例将将 MySQL 切换到离线模式（通过将系统变量offline_mode设置为ON）。在此模式下，连接的客户端用户在下一次请求时将被断开连接，不再接受连接，但具有CONNECTION_ADMIN权限（或已弃用的SUPER权限）的客户端用户除外。Group Replication 还将系统变量super_read_only设置为ON，因此即使使用CONNECTION_ADMIN或SUPER权限连接，客户端也无法进行任何更新。OFFLINE_MODE退出操作从 MySQL 8.0.18 开始提供。
  当group_replication_exit_state_action设置为ABORT_SERVER时，如果成员意外退出组或耗尽自动重新加入尝试次数，则实例将关闭 MySQL。此设置从 MySQL 8.0.12（添加系统变量时）到 MySQL 8.0.15（含）期间为默认设置。
  重要提示
  如果成员成功加入组之前发生故障，则指定的退出操作不会执行。如果在本地配置检查期间发生故障，或者加入成员的配置与组的配置不匹配，则会出现这种情况。在这些情况下，super_read_only系统变量保持其原始值，继续接受连接，并且服务器不会关闭 MySQL。因此，为了确保在 Group Replication 未启动时服务器无法接受更新，我们建议在服务器启动时在配置文件中设置super_read_only=ON，Group Replication 在成功启动后会将其更改为OFF。当服务器配置为在服务器启动时启动 Group Replication（group_replication_start_on_boot=ON命令手动启动 Group Replication 时也很有用。
  有关使用此选项的更多信息以及采取退出操作的全部情况，请参见 Section 20.7.7.4, “退出操作”。
• group_replication_flow_control_applier_threshold

• 此系统变量的值可以在 Group Replication 运行时更改，并立即生效。
  group_replication_flow_control_applier_threshold指定了在应用程序队列中等待的事务数量，触发流量控制。
• group_replication_flow_control_certifier_threshold

• 此系统变量的值可以在 Group Replication 运行时更改，并立即生效。
  group_replication_flow_control_certifier_threshold 指定了在认证者队列中等待的事务数量触发流量控制。
• group_replication_flow_control_hold_percent

• 此系统变量的值可以在 Group Replication 运行时更改，并立即生效。
  group_replication_flow_control_hold_percent 定义了集群配额剩余未使用的百分比，以允许处于流量控制状态的集群赶上积压工作。 值为 0 意味着没有配额的任何部分用于赶上工作积压。
• group_replication_flow_control_max_quota

• 此系统变量的值可以在 Group Replication 运行时更改，并立即生效。
  group_replication_flow_control_max_quota 定义了组的最大流量控制配额，或者在启用流量控制时任何时期的最大可用配额。值为 0 意味着没有设置最大配额。此系统变量的值不能小于group_replication_flow_control_min_quota和group_replication_flow_control_min_recovery_quota。
• group_replication_flow_control_member_quota_percent

• 此系统变量的值可以在 Group Replication 运行时更改，并立即生效。
  group_replication_flow_control_member_quota_percent 定义了成员在计算配额时应该假定自己可用的配额百分比。值为 0 意味着配额应该在上一个时期是写入者的成员之间均匀分配。
• group_replication_flow_control_min_quota

• 此系统变量的值可以在 Group Replication 运行时更改，并立即生效。
  group_replication_flow_control_min_quota 控制着可以分配给成员的最低流量控制配额，独立于上一个周期执行的计算最小配额。数值为 0 意味着没有最低配额。此系统变量的值不能大于group_replication_flow_control_max_quota。
• group_replication_flow_control_min_recovery_quota

• 此系统变量的值可以在 Group Replication 运行时更改，并立即生效。
  group_replication_flow_control_min_recovery_quota 控制着因为组中另一个正在恢复的成员而可以分配给成员的最低配额，独立于上一个周期执行的计算最小配额。数值为 0 意味着没有最低配额。此系统变量的值不能大于group_replication_flow_control_max_quota。
• group_replication_flow_control_mode

• 此系统变量的值可以在 Group Replication 运行时更改，并立即生效。
  group_replication_flow_control_mode 指定了流量控制的模式。
• group_replication_flow_control_period

• 此系统变量的值可以在 Group Replication 运行时更改，并立即生效。
  group_replication_flow_control_period 定义了在流量控制迭代之间等待多少秒，其中发送流量控制消息并运行流量控制管理任务。
• group_replication_flow_control_release_percent

• 此系统变量的值可以在 Group Replication 运行时更改，并立即生效。
  group_replication_flow_control_release_percent 定义了当流量控制不再需要限制写入成员时，如何释放组配额，其中百分比是每个流量控制周期的配额增加。 值为 0  意味着一旦流量控制阈值在限制范围内，配额就会在单个流量控制迭代中释放。 该范围允许配额释放高达当前配额的 10  倍，这样可以更好地适应，主要是当流量控制周期较长且配额非常小时。
• group_replication_force_members

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