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

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

一致性中使用的内存

事务一致性保证的内存分配是consistent_members_that_must_prepare_transaction、consistent_transactions、consistent_transactions_prepared、consistent_transactions_waiting和consistent_transactions_delayed_view_change事件值的总和。例如：

mysql> SELECT * FROM (
                  SELECT
                    (CASE
                       WHEN EVENT_NAME = 'memory/group_rpl/consistent_members_that_must_prepare_transaction'
                       THEN 'memory/group_rpl/consistency'
                       WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions'
                       THEN 'memory/group_rpl/consistency'
                       WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions_prepared'
                       THEN 'memory/group_rpl/consistency'
                       WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions_waiting'
                       THEN 'memory/group_rpl/consistency'
                       WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions_delayed_view_change'
                       THEN 'memory/group_rpl/consistency'
                       ELSE 'memory_gr_rest'
                     END) AS EVENT_NAME, SUM(COUNT_ALLOC), SUM(COUNT_FREE),
                    SUM(SUM_NUMBER_OF_BYTES_ALLOC),
                    SUM(SUM_NUMBER_OF_BYTES_FREE), SUM(LOW_COUNT_USED),
                    SUM(CURRENT_COUNT_USED), SUM(HIGH_COUNT_USED),
                    SUM(LOW_NUMBER_OF_BYTES_USED), SUM(CURRENT_NUMBER_OF_BYTES_USED),
                    SUM(HIGH_NUMBER_OF_BYTES_USED)
                  FROM performance_schema.memory_summary_global_by_event_name
                  GROUP BY (CASE
                              WHEN EVENT_NAME = 'memory/group_rpl/consistent_members_that_must_prepare_transaction'
                              THEN 'memory/group_rpl/consistency'
                              WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions'
                              THEN 'memory/group_rpl/consistency'
                              WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions_prepared'
                              THEN 'memory/group_rpl/consistency'
                              WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions_waiting'
                              THEN 'memory/group_rpl/consistency'
                              WHEN EVENT_NAME = 'memory/group_rpl/consistent_transactions_delayed_view_change'
                              THEN 'memory/group_rpl/consistency'
                              ELSE 'memory_gr_rest'
                            END)
      ) f
      WHERE f.EVENT_NAME != 'memory_gr_rest'\G
      *************************** 1\. row ***************************
                        EVENT_NAME: memory/group_rpl/consistency
                       COUNT_ALLOC: 16
                        COUNT_FREE: 6
         SUM_NUMBER_OF_BYTES_ALLOC: 1464
          SUM_NUMBER_OF_BYTES_FREE: 528
                    LOW_COUNT_USED: 0
                CURRENT_COUNT_USED: 10
                   HIGH_COUNT_USED: 11
          LOW_NUMBER_OF_BYTES_USED: 0
      CURRENT_NUMBER_OF_BYTES_USED: 936
         HIGH_NUMBER_OF_BYTES_USED: 1024

交付消息服务中使用的内存

注意

此仪表适用于接收的数据，而不是发送的数据。

组复制交付消息服务的内存分配是message_service_received_message和message_service_queue事件值的总和。例如：

mysql> SELECT * FROM (
                  SELECT
                    (CASE
                       WHEN EVENT_NAME = 'memory/group_rpl/message_service_received_message'
                       THEN 'memory/group_rpl/message_service'
                       WHEN EVENT_NAME = 'memory/group_rpl/message_service_queue'
                       THEN 'memory/group_rpl/message_service'
                       ELSE 'memory_gr_rest'
                     END) AS EVENT_NAME, SUM(COUNT_ALLOC), SUM(COUNT_FREE),
                    SUM(SUM_NUMBER_OF_BYTES_ALLOC),
                    SUM(SUM_NUMBER_OF_BYTES_FREE), SUM(LOW_COUNT_USED),
                    SUM(CURRENT_COUNT_USED), SUM(HIGH_COUNT_USED),
                    SUM(LOW_NUMBER_OF_BYTES_USED), SUM(CURRENT_NUMBER_OF_BYTES_USED),
                    SUM(HIGH_NUMBER_OF_BYTES_USED)
                  FROM performance_schema.memory_summary_global_by_event_name
                  GROUP BY (CASE
                              WHEN EVENT_NAME = 'memory/group_rpl/message_service_received_message'
                              THEN 'memory/group_rpl/message_service'
                              WHEN EVENT_NAME = 'memory/group_rpl/message_service_queue'
                              THEN 'memory/group_rpl/message_service'
                              ELSE 'memory_gr_rest'
                            END)
       ) f
       WHERE f.EVENT_NAME != 'memory_gr_rest'\G
       *************************** 1\. row ***************************
                         EVENT_NAME: memory/group_rpl/message_service
                        COUNT_ALLOC: 2
                         COUNT_FREE: 0
          SUM_NUMBER_OF_BYTES_ALLOC: 1048664
           SUM_NUMBER_OF_BYTES_FREE: 0
                     LOW_COUNT_USED: 0
                 CURRENT_COUNT_USED: 2
                    HIGH_COUNT_USED: 2
           LOW_NUMBER_OF_BYTES_USED: 0
       CURRENT_NUMBER_OF_BYTES_USED: 1048664
          HIGH_NUMBER_OF_BYTES_USED: 1048664

用于广播和接收事务的内存

用于广播和接收网络中事务的内存分配是wGcs_message_data::m_buffer和GCS_XCom::xcom_cache事件值的总和。例如：

mysql> SELECT * FROM (
         SELECT
           (CASE
              WHEN EVENT_NAME = 'memory/group_rpl/Gcs_message_data::m_buffer'
              THEN 'memory/group_rpl/memory_gr'
              WHEN EVENT_NAME = 'memory/group_rpl/GCS_XCom::xcom_cache'
              THEN 'memory/group_rpl/memory_gr'
              ELSE 'memory_gr_rest'
            END) AS EVENT_NAME, SUM(COUNT_ALLOC), SUM(COUNT_FREE),
           SUM(SUM_NUMBER_OF_BYTES_ALLOC),
           SUM(SUM_NUMBER_OF_BYTES_FREE), SUM(LOW_COUNT_USED),
           SUM(CURRENT_COUNT_USED), SUM(HIGH_COUNT_USED),
           SUM(LOW_NUMBER_OF_BYTES_USED), SUM(CURRENT_NUMBER_OF_BYTES_USED),
           SUM(HIGH_NUMBER_OF_BYTES_USED)
         FROM performance_schema.memory_summary_global_by_event_name
         GROUP BY (CASE
                     WHEN EVENT_NAME = 'memory/group_rpl/Gcs_message_data::m_buffer'
                     THEN 'memory/group_rpl/memory_gr'
                     WHEN EVENT_NAME = 'memory/group_rpl/GCS_XCom::xcom_cache'
                     THEN 'memory/group_rpl/memory_gr'
                     ELSE 'memory_gr_rest'
                   END)
       ) f
       WHERE f.EVENT_NAME != 'memory_gr_rest'\G
       *************************** 1\. row ***************************
                              EVENT_NAME: memory/group_rpl/memory_gr
                        SUM(COUNT_ALLOC): 73
                         SUM(COUNT_FREE): 20
          SUM(SUM_NUMBER_OF_BYTES_ALLOC): 1070845
           SUM(SUM_NUMBER_OF_BYTES_FREE): 5670
                     SUM(LOW_COUNT_USED): 0
                 SUM(CURRENT_COUNT_USED): 53
                    SUM(HIGH_COUNT_USED): 56
           SUM(LOW_NUMBER_OF_BYTES_USED): 0
       SUM(CURRENT_NUMBER_OF_BYTES_USED): 1065175
          SUM(HIGH_NUMBER_OF_BYTES_USED): 1065175

20.8 升级群组复制

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-upgrade.html

20.8.1 在群组中合并不同成员版本

20.8.2 群组复制离线升级

20.8.3 群组复制在线升级

本节解释了如何升级群组复制设置。升级群组成员的基本过程与升级独立实例的过程相同，请参阅 Chapter 3, Upgrading MySQL了解实际的升级过程和可用的类型。在原地升级和逻辑升级之间的选择取决于群组中存储的数据量。通常，原地升级更快，因此建议使用。您还应该参考 Section 19.5.3, “Upgrading a Replication Topology”。

在升级在线群组的过程中，为了最大化可用性，您可能需要在同一时间运行具有不同 MySQL  服务器版本的成员。群组复制包括兼容性策略，使您能够在升级过程中安全地将运行不同 MySQL  版本的成员合并到同一群组中。根据您的群组，这些策略的影响可能会影响您应该升级群组成员的顺序。有关详细信息，请参见 Section 20.8.1,  “Combining Different Member Versions in a Group”。

如果您的群组可以完全脱机，请参见 Section 20.8.2, “群组复制离线升级”。如果您的群组需要保持在线，这在生产部署中很常见，请参见 Section 20.8.3, “群组复制在线升级”，了解升级群组的不同方法以最小化停机时间。

20.8.1 在组中组合不同的成员版本

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-online-upgrade-combining-versions.html

20.8.1.1 升级期间的成员版本

20.8.1.2 组复制通信协议版本

组复制的版本与捆绑有 Group Replication 插件的 MySQL 服务器版本相对应。例如，如果一个成员运行 MySQL  5.7.26，则 Group Replication 插件的版本就是这个版本。要检查组成员上的 MySQL 服务器版本，请发出：

SELECT MEMBER_HOST,MEMBER_PORT,MEMBER_VERSION FROM performance_schema.replication_group_members;
+-------------+-------------+----------------+
| member_host | member_port | member_version |
+-------------+-------------+----------------+
| example.com |    3306     |   8.0.13       |
+-------------+-------------+----------------+

有关理解 MySQL 服务器版本和选择版本的指导，请参见 Section 2.1.2，“选择要安装的 MySQL 版本和发行版”。

为了获得最佳兼容性和性能，组中的所有成员应该运行相同版本的 MySQL  服务器，因此也应该运行相同版本的组复制。然而，在在线升级组的过程中，为了最大化可用性，您可能需要同时运行具有不同 MySQL  服务器版本的成员。根据 MySQL  版本之间的更改，您可能会在这种情况下遇到不兼容性。例如，如果在主要版本之间已弃用某个功能，则将版本组合到组中可能导致依赖于已弃用功能的成员失败。相反，如果在组中有运行较新  MySQL 版本的读写成员时向运行较旧 MySQL 版本的成员写入数据，可能会导致缺少较新版本引入的功能的成员出现问题。

为了防止这些问题，组复制包括兼容性策略，使您能够安全地将运行不同 MySQL  版本的成员组合到同一组中。成员应用这些策略来决定是否正常加入组，或以只读模式加入，或不加入组，具体取决于哪种选择能够确保加入成员和现有组成员的安全运行。在升级场景中，每个服务器必须离开组，进行升级，然后使用新的服务器版本重新加入组。此时，成员将应用其新服务器版本的策略，这可能已经与其最初加入组时应用的策略不同。

作为管理员，你可以通过配置服务器并发出 START GROUP_REPLICATION  语句，指示任何服务器尝试加入任何组。加入组或不加入组，或以只读模式加入组的决定由加入成员自己在尝试将其添加到组后进行，并由其自行实施。加入成员接收当前组成员的  MySQL 服务器版本信息，评估自己与这些成员的兼容性，并应用其自己 MySQL 服务器版本中使用的策略（而不是现有成员使用的策略）来决定是否兼容。

加入组时，加入成员应用的兼容性策略如下：

• 如果成员运行的 MySQL 服务器版本低于现有组成员运行的最低版本，则该成员不加入组。
  
• 如果成员运行的 MySQL 服务器版本与现有组成员运行的最低版本相同，则该成员正常加入组。
  
• 如果成员运行的 MySQL 服务器版本高于现有组成员运行的最低版本，则该成员加入组但保持只读模式。这种行为仅在组以多主模式运行时才有区别，因为在以单主模式运行的组中，新添加的成员默认始终为只读模式。
  

运行 MySQL 8.0.17 或更高版本的成员在检查兼容性时考虑发布的补丁版本。运行 MySQL 8.0.16 或更低版本，或 MySQL 5.7 的成员只考虑主要版本。例如，如果你有一个所有成员都运行 MySQL 版本 8.0.13 的组：

• 运行 MySQL 版本 5.7 的成员无法加入。
  
• 运行 MySQL 8.0.16 的成员正常加入（因为它考虑主要版本）。
  
• 运行 MySQL 8.0.17 的成员加入但保持只读模式（因为它考虑了补丁版本）。
  

请注意，运行 MySQL 5.7.27 之前版本的加入成员会检查所有组成员，以确定自己的 MySQL  服务器主要版本是否较低。因此，对于任何成员运行 MySQL 8.0 版本的组，它们将无法通过此检查，即使该组已经有其他运行 MySQL 5.7  的成员。从 MySQL 5.7.27 开始，加入成员只会检查运行最低主要版本的组成员，因此它们可以加入一个混合版本组，其中存在其他 MySQL  5.7 服务器。

在一个多主模式组中，成员使用不同的 MySQL Server 版本，Group Replication 会自动管理运行 MySQL  8.0.17  或更高版本的成员的读写和只读状态。如果一个成员离开组，那些运行当前最低版本的成员会自动设置为读写模式。当你将原本以单主模式运行的组改为多主模式时，使用group_replication_switch_to_multi_primary_mode()函数，Group Replication 会自动将成员设置为正确的模式。如果某些成员运行的 MySQL 服务器版本高于组中最低版本，那么它们会自动被设置为只读模式，而运行最低版本的成员会被设置为读写模式。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-compatibility-upgrade.html

20.8.1.1 升级过程中的成员版本

在在线升级过程中，如果组处于单主模式，则所有当前未脱机升级的服务器将像以前一样运行。每当需要时，组会选举新的主服务器，遵循第  20.1.3.1  节“单主模式”中描述的选举策略。请注意，如果您要求主服务器在整个过程中保持不变（除非它本身正在升级），则必须首先将所有次要服务器升级到高于或等于目标主服务器版本的版本，然后最后升级主服务器。主服务器不能保持为主服务器，除非它正在运行组中最低的  MySQL 服务器版本。主服务器升级后，您可以使用group_replication_set_as_primary()函数重新任命它为主服务器。

如果组处于多主模式，则在升级过程中可用于执行写操作的在线成员较少，因为升级后的成员在升级后以只读模式加入。从 MySQL 8.0.17  开始，这适用于补丁版本之间的升级，对于较低版本，这仅适用于主要版本之间的升级。当所有成员都升级到相同版本时，从 MySQL 8.0.17  开始，它们都会自动切换回读写模式。对于早期版本，您必须在每个应在升级后充当主服务器的成员上手动将super_read_only设置为OFF。

为了处理问题情况，例如如果您必须回滚升级或在紧急情况下增加组的额外容量，可以允许成员加入在线组，尽管其运行的 MySQL 服务器版本低于其他组成员使用的最低版本。在这种情况下，可以使用 Group Replication 系统变量group_replication_allow_local_lower_version_join来覆盖正常的兼容性策略。

重要提示

将group_replication_allow_local_lower_version_join设置为ON并不使新成员与组兼容；这样做允许其加入组，而没有任何防范措施来防止现有成员的不兼容行为。因此，这必须仅在特定情况下小心使用，并且您必须采取额外预防措施，以避免新成员由于正常组活动而失败。有关此变量的更多信息，请参阅其描述。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-compatibility-communication.html

20.8.1.2 Group Replication 通信协议版本

复制组使用的 Group Replication 通信协议版本可能与成员的 MySQL Server 版本不同。要检查组的通信协议版本，请在任何成员上发出以下语句：

SELECT group_replication_get_communication_protocol();

返回值显示了可以加入此组并使用组通信协议的最旧 MySQL Server 版本。从 MySQL 5.7.14 版本开始允许消息压缩，而从 MySQL 8.0.16 版本开始还允许消息分段。请注意，group_replication_get_communication_protocol() 函数返回组支持的最低 MySQL 版本，这可能与传递给 group_replication_set_communication_protocol() 函数的版本号不同，并且可能与在使用该函数的成员上安装的 MySQL Server 版本不同。

当您将复制组的所有成员升级到新的 MySQL Server 版本时，Group Replication 通信协议版本不会自动升级，以防仍然需要允许早期版本的成员加入。如果您不需要支持旧版本成员，并希望允许升级后的成员使用任何新增的通信功能，在升级后使用 group_replication_set_communication_protocol() 函数升级通信协议，指定您已将成员升级到的新 MySQL Server 版本。有关更多信息，请参见 Section 20.5.1.4, “Setting a Group’s Communication Protocol Version”。

20.8.2 Group Replication 离线升级

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-offline-upgrade.html

要执行 Group Replication  组的离线升级，您需要将每个成员从组中移除，对成员进行升级，然后像往常一样重新启动组。在多主组中，您可以以任何顺序关闭成员。在单主组中，首先关闭每个次要成员，然后最后关闭主要成员。参见第  20.8.3.2 节，“升级 Group Replication 成员”了解如何从组中移除成员并关闭 MySQL。

一旦组离线，升级所有成员。参见第三章，升级 MySQL了解如何执行升级。当所有成员都升级完毕后，重新启动成员。

如果在组离线时升级所有复制组成员，然后重新启动组，成员将使用新版本的 Group Replication 通信协议版本加入，因此该版本将成为组的通信协议版本。如果您有要求允许较早版本的成员加入，您可以使用group_replication_set_communication_protocol()函数降级通信协议版本，指定具有最旧安装服务器版本的潜在组成员的 MySQL 服务器版本。

20.8.3 集群复制在线升级

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-online-upgrade.html

20.8.3.1 在线升级考虑事项

20.8.3.2 升级集群复制成员

20.8.3.3 集群复制在线升级方法

20.8.3.4 使用mysqlbackup进行集群复制升级

当您有一个正在运行的集群需要升级，但您需要保持集群在线以提供应用程序服务时，您需要考虑升级的方法。本节描述了在线升级涉及的不同元素，以及如何升级您的集群的各种方法。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-online-upgrade-considerations.html

20.8.3.1 在线升级注意事项

在升级在线组时，您应考虑以下几点：

• 无论您如何升级您的组，重要的是在他们准备重新加入组之前禁用对组成员的任何写入。
  
• 当成员停止时，super_read_only 变量会自动设置为打开，但此更改不会持久保存。
  
• 当 MySQL 5.7.22 或 MySQL 8.0.11 尝试加入运行 MySQL 5.7.21 或更低版本的组时，它无法加入该组，因为 MySQL 5.7.21 不会发送其 lower_case_table_names 的值。
  

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-upgrading-member.html

20.8.3.2 升级组复制成员

本节解释了升级组成员所需的步骤。此过程是第 20.8.3.3  节“组复制在线升级方法”描述的方法的一部分。升级组成员的过程对所有方法都是通用的，并首先进行解释。加入升级成员的方式可能取决于您正在遵循的方法，以及诸如组是在单主还是多主模式下运行等其他因素。您如何升级服务器实例，无论是使用就地升级还是预置方法，都不会影响此处描述的方法。

升级成员的过程包括将其从组中移除，按照您选择的升级成员的方法进行升级，然后将升级后的成员重新加入组。在单主组中升级成员的推荐顺序是先升级所有次要成员，然后最后再升级主要成员。如果在次要成员之前升级主要成员，则会选择使用旧版  MySQL 版本的新主要成员，但这一步是不必要的。

要升级组的成员：

• 连接客户端到组成员并发出STOP GROUP_REPLICATION。在继续之前，请通过监视replication_group_members表确保成员的状态为OFFLINE。
  
• 禁用自动启动组复制，以便您可以安全地在升级后连接到成员并进行配置，而不会在设置group_replication_start_on_boot=0后重新加入组。
  重要
  如果升级的成员设置了group_replication_start_on_boot=1，那么在你执行 MySQL 升级过程之前，它可能会重新加入组，并可能导致问题。例如，如果升级失败并且服务器再次重启，那么可能会尝试加入组的是一个可能损坏的服务器。
  
• 停止成员，例如使用mysqladmin shutdown或SHUTDOWN语句。组中的其他成员继续运行。
  
• 使用就地或配置方法升级成员。有关详细信息，请参见第三章，升级 MySQL。在重新启动升级后的成员时，因为group_replication_start_on_boot设置为 0，Group Replication 不会在实例上启动，因此它不会重新加入组。
  
• 一旦在成员上执行了 MySQL 升级过程，必须将group_replication_start_on_boot设置为 1，以确保在重新启动后正确启动 Group Replication。重新启动成员。
  
• 连接到升级后的成员并发出START GROUP_REPLICATION。这将重新加入成员到组中。升级服务器上已经存在 Group Replication 元数据，因此通常不需要重新配置 Group Replication。服务器必须赶上在其离线时组处理的任何事务。一旦赶上组，它就成为组的在线成员。
  注意
  升级服务器所需的时间越长，该成员离线的时间就越长，因此在重新添加到组中时，服务器需要花费更多时间来赶上。
  

当升级后的成员加入任何运行较早 MySQL 服务器版本的组时，升级后的成员会以super_read_only=on加入。这确保在所有成员都运行新版本之前，不会向升级后的成员进行写入。在多主模式组中，当升级成功完成并且组准备好处理事务时，打算作为可写主节点的成员必须设置为读写模式。从  MySQL 8.0.17  开始，当组的所有成员都升级到相同版本时，它们都会自动切换回读写模式。对于早期版本，您必须手动将每个成员设置为读写模式。连接到每个成员并发出：

SET GLOBAL super_read_only=OFF;

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-online-upgrade-methods.html

20.8.3.3 Group Replication Online Upgrade Methods

选择以下升级 Group Replication 组的方法之一：

滚动式组内升级

只要运行较新版本的服务器不会在仍有较旧版本的服务器的情况下向组生成工作负载，此方法就受支持。换句话说，只有运行较新版本的服务器可以作为辅助服务器加入组。在此方法中，只有一个组，每个服务器实例都会从组中移除，升级，然后重新加入组。

此方法非常适用于单主组。当组以单主模式运行时，如果您要求主服务器在整个过程中保持不变（除非正在升级自身），则应将其作为最后一个升级的成员。主服务器必须在组中运行最低版本的 MySQL 服务器版本才能保持为主服务器。主服务器升级后，您可以使用group_replication_set_as_primary()函数将其重新指定为主服务器。如果您不在意哪个成员是主服务器，那么成员可以以任何顺序进行升级。组在必要时从运行最低 MySQL 服务器版本的成员中选举新的主服务器，遵循第 20.1.3.1 节，“单主模式”中描述的选举策略。

对于以多主模式运行的组，在组内滚动升级期间，主服务器数量会减少，导致写入可用性降低。这是因为如果成员在组运行时加入组，而其运行的 MySQL 服务器版本高于现有组成员运行的最低版本，则它会自动保持为只读模式（super_read_only=ON）。请注意，运行  MySQL 8.0.17 或更高版本的成员在检查时会考虑发布的补丁版本，但运行 MySQL 8.0.16 或更低版本，或 MySQL 5.7  的成员只会考虑主要版本。当所有成员升级到相同版本后，从 MySQL 8.0.17  开始，它们会自动恢复为读写模式。对于早期版本，您必须在每个成员上手动设置super_read_only=OFF，以便在升级后作为主服务器运行。

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

滚动式迁移升级

在这种方法中，您将从组中移除成员，升级它们，然后使用升级后的成员创建第二组。对于在多主模式下运行的组，在此过程中主节点的数量会减少，导致写入可用性降低。这不会影响在单主模式下运行的组。

因为在升级成员时运行较旧版本的组在线，所以需要运行较新版本的组赶上在升级成员时执行的任何事务。因此，新组中的一个服务器被配置为较旧组的主节点的副本。这确保新组赶上较旧组。由于此方法依赖于用于将数据从一个组复制到另一个组的异步复制通道，因此它在异步源-副本复制的相同假设和要求下受支持，参见  Chapter 19, 复制。对于在单主模式下运行的组，向旧组的异步复制连接必须发送数据到新组的主节点，对于多主组，异步复制通道可以连接到任何主节点。

过程如下：

• 逐个从运行较旧服务器版本的原始组中移除成员，参见 Section 20.8.3.2, “升级组复制成员”
  
• 升级运行在成员上的服务器版本，参见 Chapter 3, 升级 MySQL。您可以选择进行就地升级或预置升级的方法。
  
• 创建一个具有升级成员的新组，参见 Chapter 20, 组复制。在这种情况下，您需要在每个成员上配置一个新组名称（因为旧组仍在运行并使用旧名称），引导一个初始升级成员，然后添加其余的升级成员。
  
• 在旧组和新组之间建立一个异步复制通道，参见 Section 19.1.3.4, “使用 GTIDs 设置复制”。将较旧的主节点配置为异步复制源服务器，将新组成员配置为基于 GTID 的副本。
  

在将应用程序重定向到新组之前，您必须确保新组具有合适数量的成员，例如使组能够处理成员的故障。执行SELECT * FROM performance_schema.replication_group_members并比较初始组大小和新组大小。等到所有旧组的数据传播到新组，然后删除异步复制连接并升级任何缺失的成员。

滚动复制升级

在这种方法中，您创建一个由运行较新版本的成员组成的第二组，并将旧组缺失的数据复制到较新组。这假定您有足够的服务器同时运行两个组。由于在此过程中主服务器的数量不减少，对于运行在多主模式下的组来说，写入可用性不会减少。这使得滚动复制升级非常适合在多主模式下运行的组。这不会影响在单主模式下运行的组。

因为在为新组的成员提供资源时，运行旧版本的组在线，您需要确保运行较新版本的组赶上在为成员提供资源时执行的任何事务。因此，新组中的一个服务器被配置为旧组的主服务器的副本。这确保新组赶上旧组。由于此方法依赖于用于将数据从一个组复制到另一个组的异步复制通道，因此它在相同的异步源-副本复制的假设和要求下受支持，请参阅第十九章，复制。对于在单主模式下运行的组，异步复制连接到旧组必须将数据发送到新组的主服务器，对于多主组，异步复制通道可以连接到任何主服务器。

过程是：

• 部署适当数量的成员，以便运行较新版本的组可以处理成员的故障
  
• 对组中的一个成员进行现有数据的备份
  
• 使用来自旧成员的备份为新组的成员提供资源，请参阅第 20.8.3.4 节，“使用mysqlbackup进行组复制升级”中的一种方法。
  注意
  您必须将备份还原到与备份所在的 MySQL 版本相同的版本，然后执行就地升级。有关说明，请参阅第三章，升级 MySQL。
  
• 创建一个包含升级成员的新组，请参阅第二十章，组复制。在这种情况下，您需要在每个成员上配置一个新的组名（因为旧组仍在运行并使用旧名称），引导一个初始升级成员，然后添加其余的升级成员。
  
• 在旧组和新组之间建立一个异步复制通道，请参阅第 19.1.3.4 节，“使用 GTIDs 设置复制”。将较旧的主服务器配置为异步复制源服务器，将新组成员配置为基于 GTID 的副本。
  

一旦新组中缺失的持续数据量足够小，可以快速传输，您必须将写操作重定向到新组。等到所有旧组的数据传播到新组，然后断开异步复制连接。

原文：dev.mysql.com/doc/refman/8.0/en/group-replication-upgrade-with-mysqlbackup.html

20.8.3.4 使用mysqlbackup进行组复制升级

作为一种供应方法的一部分，您可以使用 MySQL 企业备份将数据从一个组成员复制并恢复到新成员。但是，您不能直接使用此技术将从运行较旧版本  MySQL 的成员中获取的备份直接恢复到运行较新版本 MySQL 的成员。解决方案是将备份恢复到运行与备份来源成员相同版本 MySQL  的新服务器实例，然后升级该实例。此过程包括：

• 从较旧组的成员使用mysqlbackup进行备份。参见第 20.5.6 节，“使用 MySQL 企业备份与组复制”。
  
• 部署一个新的服务器实例，该实例必须运行与获取备份的较旧成员相同版本的 MySQL。
  
• 使用mysqlbackup将备份从较旧成员恢复到新实例。
  
• 在新实例上升级 MySQL，请参见第三章，升级 MySQL。
  

重复此过程以创建适当数量的新实例，例如以处理故障转移。然后根据第 20.8.3.3 节，“组复制在线升级方法”将实例加入到组中。

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