Mysql8.4参考手册走读（四）

第 19 章 复制

MySQL复制支持从一个MySQL数据库服务器（称为source）复制到一个或多个MySQL数据库服务器（称为副本）。默认情况下，复制是异步的，副本不需要永久连接才能接收来自源的更新。根据配置，您可以复制所有数据库、选定的数据库，甚至是数据库中的选定表。

MySQL复制的优点包括：

1. 横向扩展解决方案：在多个副本之间分配负载以提高性能。在此环境中，所有写入和必须在源服务器上进行更新。然而，阅读可能发生在一个或多个副本上。这种模式可以改进写入的性能（因为源代码专用于updates），同时显著提高读取速度增加副本数量。

2. 数据安全性：因为副本可以暂停复制过程中，可以在副本上运行备份服务而不会损坏相应的源数据。

3. 分析：可以在源上创建实时数据，而在副本上对信息进行分析不影响源的性能。

4. 远距离数据分发：您可以使用复制来创建数据的本地副本供远程站点使用，而无需永久访问源。

有关如何在此类方案中使用复制的信息，请参见第19.4节“复制解决方案”。

MySQL 8.4支持不同的复制方法。传统方法基于从source的二进制日志，并且需要日志文件和它们将在源和副本之间同步。较新的方法基于全球交易标识符（GTID）是事务性的，因此确实如此不需要处理日志文件或这些文件中的位置，这大大简化了许多常见的复制任务。复制使用GTID可保证源和副本之间的一致性，因为只要在源上提交的所有事务也已应用于复本。有关GTID和MySQL中基于GTID的复制，请参见第19.1.3节“使用全局事务标识符进行复制”。有关使用二进制文件的信息基于日志文件位置的复制，请参见第19.1节“配置复制”。

MySQL中的复制支持不同类型的同步。原始的同步类型是单向、异步的复制，其中一台服务器充当源，而一台或更多其他服务器充当副本。这与同步复制形成鲜明对比，同步复制是NDB Cluster的特征（参见第25章，MySQL NDB Cluster 8.4）。在MySQL 8.4中，支持半同步复制除了内置的异步复制。跟半同步复制，在源块上执行的提交在返回到执行事务的会话之前，直到至少有一个副本确认它已接收并记录交易的事件；请参见第19.4.10节“半同步复制”。MySQL 8.4也支持延迟复制，以便副本故意滞后至少落后于源指定的时间；请参见第19.4.11节“延迟复制”。对于需要同步复制的方案，请使用NDB集群（参见第25章MySQL NDB Cluster 8.4）。

有许多解决方案可用于设置复制在服务器之间，最佳使用方法取决于是否存在数据和您正在使用的引擎类型。有关的更多信息可用选项，请参见第19.1.2节“设置基于二进制日志文件位置的复制”。

有两种核心类型的复制格式：基于语句复制（SBR），用于复制整个SQL语句，以及Row基于复制（RBR），仅复制更改的行。您还可以使用第三种变体，即基于混合的复制（MBR）。为有关不同复制格式的更多信息，请参见第19.2.1节“复制格式”。

复制通过许多不同的选项进行控制，并且变量。有关更多信息，请参见第19.1.6节“复制和二进制日志记录选项和变量”。其他安全措施可以应用于复制拓扑，如第19.3节“复制安全性”中所述。

您可以使用复制来解决许多不同的问题，包括性能，支持不同数据库的备份，并作为缓解系统故障的更大解决方案的一部分。为有关如何解决这些问题的信息，请参见第19.4节“复制解决方案”。

有关不同数据类型和语句的注释和提示在复制期间处理，包括复制的详细信息功能、版本兼容性、升级和潜在问题及其解决方法，请参见第19.5节“复制说明和提示”。为MySQL新手经常问的一些问题的答案复制，请参见第A.14节“MySQL 8.4常见问题解答：复制”。

有关实现复制的详细信息，请执行以下操作复制工作，二进制日志的过程和内容，后台线程和用于决定语句的规则记录和复制，请参见第19.2节“复制实现”。

19.1 配置复制

19.1.1 二进制日志文件基于位置的复制配置概述

本节介绍的是MySQL服务器之间的复制方法，这种方法基于二进制日志文件位置。在这种方法中，MySQL实例作为源操作（即发生数据库更改的地方），将更新和更改作为“事件”写入二进制日志文件。二进制日志中的信息根据所记录的数据库更改以不同的格式存储。

副本被配置为从源读取二进制日志，并在副本的本地数据库中执行这些事件。每个副本都会接收到二进制日志的全部内容。副本负责决定哪些语句应该执行。默认情况下，除非指定，否则副本将执行源二进制日志中的所有事件。如果需要，您可以配置副本仅处理适用于特定数据库或表的事件。

重要的是，不能将源配置为仅记录某些事件。每个副本都保留有二进制日志坐标的记录：文件名以及它在该文件中已读取的位置，以及它已从源处理的位置。这意味着多个副本可以连接到源并执行相同的二进制日志。由于副本控制此过程，单个副本可以连接和断开与服务器的连接，而不会影响源的运行。另外，因为每个副本记录了二进制日志中的当前位置，所以副本可以在断开连接后重新连接，并恢复处理。

源和每个副本必须配置一个唯一的ID（使用server_id系统变量）。此外，每个副本还必须配置有关源的主机名、日志文件名以及该文件中的位置。这些细节可以通过在MySQL会话中使用CHANGE REPLICATION SOURCE TO语句在副本上进行控制。这些详细信息存储在副本的连接元数据存储库中（参见第19.2.4节“中继日志和复制元数据存储库”）。

19.1.2 设置二进制日志文件基于位置的复制

本节介绍了如何设置MySQL服务器以使用基于二进制日志文件位置的复制。以下是一些通用任务：

1. 在源上，必须确保启用二进制日志记录，并配置唯一的服务器ID。这可能需要服务器重新启动。请参见第19.1.2.1节“设置复制源配置”。

2. 在要连接到源的每个副本上，您必须配置唯一的服务器ID。这可能需要服务器重新启动。请参见第19.1.2.2节“设置副本配置”。

3. （可选）为副本创建单独的用户以供使用在与源进行身份验证期间，读取二进制文件时用于复制的日志。请参见第19.1.2.3节“创建用于复制的用户”。

4. 在创建数据快照或开始复制之前进程，在源上应记录当前位置在二进制日志中。配置时需要此信息副本，以便副本知道二进制文件中的位置log开始执行事件。请参见第19.1.2.4节“获取复制源二进制日志坐标”。

5. 如果您已经有源上的数据并希望使用它来同步副本，需要创建数据快照将数据复制到副本。您正在使用的存储引擎对创建快照的方式有影响。当你是使用MyISAM，您必须停止处理源上的语句以获取读锁，然后获取其当前二进制日志坐标并转储其数据，然后允许源继续执行语句。如果不停止语句的执行，数据转储和源状态信息变为不匹配，导致数据库不一致或损坏在副本上。有关复制MyISAM源的更多信息，请参见第19.1.2.4节“获取复制源二进制日志坐标”。如果你是使用InnoDB，您不需要read-lock和足够长的事务来传输数据快照就足够了。有关更多信息，请参见第17.19节“InnoDB和MySQL复制”。

6. 使用用于连接到源，例如主机名、登录凭据和二进制文件日志文件名和位置。请参见第19.1.2.7节“在副本上设置源配置”。

7. 在源和副本，以适合您的系统。请参见第19.3节“复制安全性”。

注意：设置过程中的某些步骤需要SUPER权限。如果你没有此权限，则可能无法启用复制。

配置基本选项后，选择方案：

• 为全新安装的源设置复制，以及不包含数据的副本，请参见第19.1.2.6.1节“使用新源和副本设置复制”。
• 使用来自现有的MySQL服务器，请参见第19.1.2.6.2节“使用现有数据设置复制”。
• 要将副本添加到现有复制环境，请参见第19.1.2.8节“将副本添加到复制环境”。

在管理MySQL复制服务器之前，请阅读整个内容章节并尝试第15.4.1节“用于控制源服务器的SQL语句”和第15.4.2节“用于控制副本服务器的SQL语句”中提到的所有语句。还要熟悉您自己使用第19.1.6节“复制和二进制日志记录选项和变量”中描述的复制启动选项。

19.1.2.1 设置复制源配置

在配置源服务器以使用基于二进制日志文件位置的复制时，必须确保启用了二进制日志记录，并设置一个唯一的服务器ID。以下是配置源服务器的关键步骤和注意事项：

关键步骤

1. 启用二进制日志记录：默认情况下，二进制日志记录是启用的（log_bin 系统变量设置为 ON）。二进制日志是复制过程中从源到副本传递更改的必要条件。

2. 设置服务器ID：每台参与复制的服务器必须拥有一个唯一的服务器ID，这可以通过server_id系统变量来指定。服务器ID的值应该是1到2^32-1之间的正整数，并且每个服务器的ID必须唯一。

   SET GLOBAL server_id = 2;
   

   如果之前设置了值为0的服务器ID，则必须重新启动服务器才能应用新的非零服务器ID。

注意事项

1. 服务器ID的选择和组织：服务器ID的选择是任意的，只要保证每个ID是唯一的且不与其他服务器冲突。

2. 二进制日志文件名：使用--log-bin选项可以指定二进制日志文件的基本名称。建议提供非默认基名，以便在主机名更改后，可以轻松地继续使用相同的二进制日志文件名称。

3. 二进制日志记录的禁用与启用：如果之前使用--skip-log-bin选项禁用了二进制日志记录，需要在没有此选项的情况下重新启动服务器以启用它。

4. InnoDB的配置：为了获得最大的耐用性和一致性，当使用InnoDB进行事务复制时，应在源的配置文件(my.cnf)中设置以下参数：

   innodb_flush_log_at_trx_commit=1
   sync_binlog=1
   

5. 网络配置：确保skip_networking系统变量在源服务器上未启用。如果禁用了网络，副本将无法与源连接，导致复制失败。

按照这些步骤和注意事项配置源服务器，可以确保基于二进制日志文件位置的复制正确进行。

19.1.2.2 设置副本配置

每个副本必须具有唯一的服务器ID，由server_id系统变量指定。如果设置多个副本，每个副本必须具有独特的server_id值，与源和其他副本不同。如果尚未设置副本的服务器ID，或者当前值与您选择的值冲突，您必须更改它。

默认情况下，server_id值为1。您可以通过发出如下语句来动态更改server_id值：

SET GLOBAL server_id = 21;

请注意，服务器ID的值为0可防止副本连接到源。如果该服务器ID值（即default）是之前设置的，您必须重新启动服务器以使用新的非零服务器ID。否则，不需要重新启动服务器当您更改服务器ID时，除非您使其他需要它的配置更改。例如，如果二进制日志记录已在服务器上禁用，并且您希望启用它，需要重新启动服务器才能启用此功能。

如果要关闭副本服务器，则可以将配置文件的部分编辑为指定唯一的服务器ID。例如：

[mysqld]
server-id=21

默认情况下，所有服务器上都启用二进制日志记录。复制品不需要为复制启用二进制日志记录发生。但是，副本上的二进制日志记录意味着副本的二进制日志可用于数据备份和崩溃恢复。启用了二进制日志记录的副本也可以是用作更复杂的复制拓扑的一部分。例如，您可能希望使用以下命令设置复制服务器链式排列：

A -> B -> C

在这里，用作副本的源，并用作副本的源。要使此功能正常工作，必须同时是源和副本。接收的更新必须记录到它的二进制日志，以便传递给下一个副本。除了二进制日志记录之外，这复制拓扑要求系统变量log_replica_updates启用。启用副本更新后，副本将写入从源接收并由副本的SQL线程到副本自己的二进制日志。默认情况下处于启用状态。

如果需要禁用二进制日志记录或副本更新日志记录在副本上，可以通过为副本指定–skip-log-bin和–log-replica-updates=OFF选项来执行此操作。如果您决定重新启用这些复制副本上的功能，删除相关选项并重新启动服务器。

19.1.2.3 创建用于复制的用户

每个副本都使用MySQL用户名和密码，所以源上必须有一个用户帐户供副本用于连接。设置复制副本时，用户名由CHANGE REPLICATION SOURCE TO语句的选项指定。任何帐户都可以用于此操作，前提是它已被授予REPLICATION SLAVE特权。可以选择为每个副本创建不同的帐户，或者对于每个副本，使用相同的帐户连接到源。

虽然您不必专门为复制时创建帐户，但您应该知道复制用户名和密码以纯文本形式存储在副本的连接元数据存储库中（请参见第19.2.4.2节“复制元数据存储库”）。因此，您可能想要创建一个仅具有复制过程的单独帐户，以最大程度地减少入侵到其他帐户的可能性。

要创建新帐户，请使用CREATE USER语句。授予此帐户所需的权限对于复制，请使用GRANT语句。如果您仅出于以下目的创建帐户replication，则该帐户只需要REPLICATION SLAVE权限。例如，要设置一个新用户，可以允许从域内的任何主机进行复制，请执行以下操作：

mysql> CREATE USER 'repl'@'%.example.com' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.example.com';

19.1.2.4 获取复制源二进制日志坐标

要将复制副本配置为在正确的点，您需要注意源的当前坐标在其二进制日志中。警告：此过程使用 FLUSH TABLES WITH READ LOCK，用于阻止 InnoDB 表的 COMMIT 操作。

如果计划关闭源以创建数据快照，您可以选择跳过此过程，而是存储二进制日志索引文件的副本以及数据快照。在这种情况下，源会创建一个新的二进制日志重新启动时的文件。源二进制日志坐标副本必须启动复制过程，因此该新文件的开头，该文件是 source 跟在复制的文件后面二进制日志索引文件。

若要获取源二进制日志坐标，请按照下列步骤操作：

1. 通过使用命令行客户端，并刷新所有表和块写入通过执行 FLUSH TABLES WITH READ LOCK 语句：

mysql> FLUSH TABLES WITH READ LOCK;

警告：离开发出 FLUSH TABLES 语句的客户端运行，以便读取锁保持有效。如果你退出客户端，锁被释放。

2. 在源上的其他会话中，使用 SHOW BINARY LOG STATUS 语句确定当前二进制日志文件名和位置：

mysql> SHOW BINARY LOG STATUS\G

该列显示日志的名称文件，该列显示文件中的位置。在此示例中，二进制日志 file 是 mysql-bin.000003，位置是 73。记录这些值。当你以后需要它们时设置复制副本。它们表示复制副本应开始处理新副本的坐标从源头更新。FilePositionmysql-bin.000003

如果源之前一直使用二进制文件运行已禁用日志记录，日志文件名和位置值显示由 SHOW BINARY LOG 显示 STATUS 或 mysqldump --source-data 为空。在这种情况下，稍后需要使用的值指定源的二进制日志文件和位置是空字符串（）和（‘’）。

现在，您拥有使副本能够执行以下操作所需的信息：开始从源的二进制日志中读取正确的内容开始复制的位置。

下一步取决于您是否有源。选择以下选项之一：

1. 如果现有数据需要同步副本在开始复制之前，请离开客户端运行，以便锁保持在原位。这可以防止任何正在进行进一步的更改，以便将数据复制到副本与源同步。继续执行第 19.1.2.5 节 “选择数据快照的方法”。

2. 如果要设置新的源和副本组合，您可以退出第一个会话以释放读取锁。请参见第 19.1.2.6.1 节 “使用新源和副本设置复制”，了解如何进行。

19.1.2.5 选择数据快照的方法

如果源数据库包含现有数据，则需要将此数据复制到每个副本。有不同的转储方式源数据库中的数据。以下部分描述可能的选项：

1. 使用 mysqldump 工具创建转储：这是推荐的方法，尤其是在使用InnoDB时。它可以复制所有数据库。

2. 复制原始数据文件：如果数据库存储在二进制可移植文件中，则可以将原始数据文件复制到副本。这种方法可能比使用mysqldump更快，因为它跳过了重播语句时更新索引的开销。但不建议用于InnoDB等存储引擎。

3. 使用MySQL Server的克隆插件：传输所有数据从现有副本到克隆。有关使用说明，请参见第7.6.7.7节“克隆复制”。

4. 提示：要部署多个MySQL实例，可以使用InnoDB Cluster，它使您能够在MySQL Shell中轻松管理一组MySQL服务器实例。InnoDB Cluster将MySQL组复制封装在编程环境中，使您能够轻松部署MySQL实例集群以实现高可用性。

5. 使用mysqldump创建数据快照：在现有源中创建数据的快照数据库，请使用mysqldump工具。一旦数据转储已经完成，将此数据导入到副本，然后开始复制过程。

6. 排除某些数据库：可以使用mysqldump工具从转储中排除某些数据库。如果只想包含某些数据库，不要使用–all-databases选项。可以使用–ignore-table选项排除数据库中的所有表，或使用–databases选项命名要转储的那些数据库。

7. GTID注意事项：默认情况下，如果源上正在使用GTID（gtid_mode=ON），mysqldump会包含source以将它们gtid_purged添加到复制品。如果仅转储特定数据库或表，需要注意的是，值是mysqldump包含的GTID在gtid_executed上设置的所有交易源，即使是那些改变的抑制部分数据库，或服务器上其他未包含在部分转储中。检查mysqldump的选项查找MySQL默认行为的结果您正在使用的服务器版本，以及如何更改如果此结果不适合您的情况，则行为。

19.1.2.6 设置副本

要设置副本，您需要执行以下步骤：

1. 配置源服务器的性能。请参见第 19.1.2.1 节 “设置复制源配置”。

2. 获取源状态信息或源的二进制日志索引文件以创建数据快照。请参见第 19.1.2.4 节 “获取复制源二进制日志坐标”。

3. 在源上释放读取锁：

mysql> UNLOCK TABLES;

4. 在副本上编辑MySQL配置。请参见第 19.1.2.2 节 “设置副本配置”。

5. 根据是否有现有数据导入到副本，选择以下选项之一：

   • 如果没有要导入的数据库快照，请参见第 19.1.2.6.1 节 “使用新源和副本设置复制”。
   • 如果有要导入的数据库快照，请参见第 19.1.2.6.2 节 “使用现有数据设置复制”。

6. 使用新的源和副本设置复制时，请执行以下操作：

   • 启动复制副本。
   • 执行 CHANGE REPLICATION SOURCE TO 语句以设置源的副本上的配置。请参见第 19.1.2.7 节 “在副本上设置源配置”。
   • 对每个副本执行这些副本设置步骤。

7. 如果要设置新服务器，也可以使用此方法，但具有来自不同数据库的现有转储以加载到复制中的服务器配置。通过将数据加载到新的源中，数据会自动复制到副本。

8. 如果要使用其他现有数据库服务器的数据创建新的源，则在新来源。数据库更新会自动传播到副本。

9. 使用现有数据设置复制时，请按照以下过程操作：

   • 如果您使用MySQL Server的克隆插件创建克隆，数据已经转移。否则，请将数据导入副本。
   • 如果您使用了mysqldump，请启动副本服务器，确保复制不会首先使用 --skip-replica-start 启动。然后导入转储文件。
   • 如果使用原始数据文件创建了快照，将数据文件提取到副本的数据目录中。然后启动副本服务器，确保复制不会使用 --skip-replica-start 启动。
   • 使用复制坐标配置副本从源头。这会告诉副本二进制日志文件和文件中需要复制的位置。此外，使用登录名配置副本源的凭据和主机名。
   • 通过发出 START REPLICA 语句来启动复制线程。

10. 副本将连接到源并复制自拍摄快照以来的来源。错误消息是如果副本无法发出错误日志，则发出出于任何原因复制。

11. 副本使用记录在其连接元数据中的信息来跟踪的存储库和应用元数据存储库它处理了多少源的二进制日志。默认情况下，这些存储库是数据库中名为和的表。不要删除或编辑这些表，除非您确切地知道您的内容正在做并完全理解其含义。即使那样，最好使用 CHANGE REPLICATION SOURCE TO 语句来更改复制参数。副本使用语句中指定的值，用于更新自动复制元数据存储库。有关更多信息，请参见第 19.2.4 节 “中继日志和复制元数据存储库”。

19.1.2.7 在副本上设置源配置

在副本上执行以下 CHANGE REPLICATION SOURCE TO 语句，并将选项值替换为实际值与您的系统相关：

mysql> CHANGE REPLICATION SOURCE TO
    ->     SOURCE_HOST='source_host_name',
    ->     SOURCE_USER='replication_user_name',
    ->     SOURCE_PASSWORD='replication_password',
    ->     SOURCE_LOG_FILE='recorded_log_file_name',
    ->     SOURCE_LOG_POS=recorded_log_position;

注意：复制不能使用 Unix 套接字文件。您必须能够使用 TCP/IP 连接到源 MySQL 服务器。

CHANGE REPLICATION SOURCE TO 语句还具有其他选项。例如，可以使用 SSL 设置安全复制。有关完整选项列表以及有关字符串值选项的最大允许长度的信息，请参见第 15.4.2.2 节 “将复制源更改为 Statement”。

重要提示：如果您没有使用安全连接和用户帐户在选项中命名使用插件进行身份验证（默认在 MySQL 8.4 中），必须在 CHANGE REPLICATION SOURCE TO 语句中指定 or 选项以启用基于 RSA 密钥对的密码交换。

19.1.2.8 向复制环境添加副本

1. 首先，确保在新的复制副本上禁用任何正在复制的事件，以防止在源服务器上已经运行的操作导致错误。
2. 使用MySQL服务器的克隆插件将数据和复制设置从现有副本传输到新副本。有关如何使用此方法的说明，请参阅第7.6.7.7节“克隆复制”。
3. 如果没有使用克隆插件，请按照以下步骤操作：
   • 停止现有副本并记录副本状态信息，特别是源二进制日志文件和中继日志文件位置。
   • 将数据目录从现有副本复制到新副本，包括日志文件和中继日志文件。
   • 在复制过程中，确保还复制了与现有副本相关的所有文件，例如系统表空间、撤消表空间和重做日志等。
   • 从新副本的数据目录中删除auto.cnf文件，以便新副本使用其他生成的服务器UUID启动。
4. 如果遇到新副本失败的问题，请确保还复制了现有副本的中继日志索引文件，并设置了relay_log_index系统变量以匹配现有副本。
5. 重新启动现有复制副本。
6. 在新副本上编辑配置并分配唯一的服务器ID（使用server_id系统变量）和服务器UUID。
7. 启动新的副本服务器，确保尚未通过指定–skip-replica-start选项来启动复制。使用性能模式复制表或发出SHOW REPLICA STATUS语句来确认新副本具有正确的设置。
8. 通过发出START REPLICA语句来启动复制线程。现在，新副本将使用其连接信息中的元数据存储库来启动复制过程。

19.1.3 使用全局事务标识符进行复制

MySQL 8.4 中的多源复制支持副本 并行接收来自多个直接来源的交易。 在多源复制拓扑中，副本会创建一个 它应该接收的每个源的复制通道 交易从。有关复制通道的详细信息 函数，请参见第 19.2.2 节 “复制通道”。

您可以选择实现多源复制来实现 目标如下：

将多台服务器备份到一台服务器。

合并表分片。

将数据从多台服务器合并到一台服务器。

多源复制不实现任何冲突检测 或应用事务时的解决，这些任务被遗弃 如果需要，到应用程序。

注意
多源副本上的每个通道都必须从 不同的来源。不能设置多个复制通道 从单个副本到单个源。这是因为 副本的服务器 ID 在复制拓扑中必须是唯一的。 源仅通过副本的服务器 ID 来区分副本，而不是通过 复制通道的名称，因此无法识别 来自同一副本的不同复制通道。

多源副本也可以设置为多线程副本 replica，通过将系统变量 replica_parallel_workers 设置为值 大于 0。在多源副本上执行此操作时，每个 副本上的通道具有指定数量的应用线程， 加上一个协调线程来管理它们。您无法配置 单个通道的应用线程数。

MySQL 8.4 还支持在特定 具有多源副本的复制通道。特定于渠道 当同一数据库或表 存在于多个源上，您只需要副本 从一个来源复制它。对于基于 GTID 的复制，如果 同一事务可能来自多个来源（例如在 菱形拓扑），您必须确保过滤设置相同 在所有频道上。有关更多信息，请参见第 19.2.5.4 节 “基于复制通道的筛选器”。

本节提供有关如何配置源和 用于多源复制的副本，如何启动、停止和重置 多源副本，以及如何监视多源复制。

19.1.4 更改在线服务器上的 GTID 模式

本节介绍如何从 并进入 GTID 模式，而无需使服务器脱机。

19.1.5 MySQL多源复制

整理后的下文：

MySQL 8.4 中的多源复制支持副本并行接收来自多个直接来源的交易。在多源复制拓扑中，副本会为它应接收的每个源创建一个复制通道。有关复制通道的功能详情，请参见第 19.2.2 节“复制通道”。

您可以选择实现多源复制来实现以下目标：

• 将多台服务器备份到一台服务器。
• 合并表分片。
• 将数据从多台服务器合并到一台服务器。

注意，多源复制不实现任何冲突检测或应用事务时的解决，这些任务被遗弃到应用程序中。

多源副本上的每个通道都必须来源于不同的源。不能设置多个复制通道从单个副本到单个源。这是因为在复制拓扑中，副本的服务器ID必须是唯一的。源仅通过副本的服务器ID来区分副本，而不是通过复制通道的名称，因此无法识别来自同一副本的不同复制通道。

多源副本也可以设置为多线程副本，通过将系统变量replica_parallel_workers设置为大于0的值。在多源副本上执行此操作时，每个副本上的通道具有指定数量的应用线程，加上一个协调线程来管理它们。您无法配置单个通道的应用线程数。

MySQL 8.4 还支持在特定具有多源副本的复制通道。当同一数据库或表存在于多个源上时，您只需要副本从一个来源复制它。对于基于GTID的复制，如果同一事务可能来自多个来源（例如在菱形拓扑中），您必须确保在所有频道上过滤设置相同。有关更多信息，请参见第 19.2.5.4 节“基于复制通道的筛选器”。

本节提供了有关如何配置源和用于多源复制的副本，如何启动、停止和重置多源副本，以及如何监视多源复制的信息。

19.1.6 复制和二进制日志记录选项和变量

这篇文章主要介绍了MySQL复制相关的一些系统变量和选项，包括server_id、server_uuid等。其中，server_id是一个非常重要的系统变量，它用于指定服务器的ID。在启用二进制日志记录的情况下，如果没有显式设置server_id，则会发出一条信息性消息。在复制拓扑中使用的服务器，必须为每个复制服务器指定唯一的服务器ID。

server_uuid是另一个重要的系统变量，它是MySQL服务器自动生成的UUID。在启动时，MySQL服务器会自动获取UUID并尝试读取和使用写入文件中的UUID。如果未找到，则会生成一个新的UUID并将其保存到此文件中。

文章还提到了GTID（全局事务标识符），它在源自该服务器的事务中也使用服务器UUID。在启动时，复制I/O（接收器）线程会生成一个错误，如果其源的UUID等于其自己的UUID，则中止，除非已设置–replicate-same-server-id选项。此外，复制接收器线程在某些情况下还会生成警告。

19.1.6.1 复制和二进制日志记录选项和变量参考

复制和二进制日志记录选项和变量参考

19.1.6.2 复制源选项和变量

复制源选项和变量

19.1.6.3 副本服务器选项和变量

副本服务器选项和变量

19.1.6.4 二进制日志记录选项和变量

二进制日志记录选项和变量

19.1.6.5 全局事务 ID 系统变量

局事务 ID 系统变量

19.1.7 常见复制管理任务

19.1.7.1 检查复制状态

复制管理中最常见的任务是确保复制正在进行并且已经发生 在副本和源之间没有错误。

必须在每个副本上执行的 SHOW REPLICA STATUS 语句提供有关连接的配置和状态的信息 在副本服务器和源服务器之间。MySQL 的性能架构包含提供此信息的复制表 以更易于访问的形式提供信息。请参见第 29.12.11 节 “性能架构复制表”。

性能中显示的复制检测信号信息 架构复制表允许您检查复制，即使源尚未将事件发送到 最近的复制品。源向 replica 如果没有更新，并且没有未发送的事件， 二进制日志的时间长于检测信号间隔。源上的设置 （由 CHANGE REPLICATION SOURCE 设置 TO） 指定心跳的频率，其中 默认为 连接超时间隔的一半 replica（由系统变量 replica_net_timeout 指定。replication_connection_status性能架构表显示最近检测信号的时间 信号被接收到副本，以及有多少个心跳信号 它已经收到。SOURCE_HEARTBEAT_PERIOD

您可以使用 SHOW REPLICA STATUS 检查单个副本的状态；此声明提供 如下所示的信息：

mysql> SHOW REPLICA STATUS\G
*************************** 1. row ***************************
Replica_IO_State: Waiting for source to send event
Source_Host: 127.0.0.1
Source_User: root
Source_Port: 13000
Connect_Retry: 1
Source_Log_File: master-bin.000001
Read_Source_Log_Pos: 927
Relay_Log_File: slave-relay-bin.000002
Relay_Log_Pos: 1145
Relay_Source_Log_File: master-bin.000001
Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Source_Log_Pos: 927
Relay_Log_Space: 1355
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Source_SSL_Allowed: No
Source_SSL_CA_File:
Source_SSL_CA_Path:
Source_SSL_Cert:
Source_SSL_Cipher:
Source_SSL_Key:
Seconds_Behind_Source: 0
Source_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Source_Server_Id: 1
Source_UUID: 73f86016-978b-11ee-ade5-8d2a2a562feb
Source_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Replica_SQL_Running_State: Replica has read all relay log; waiting for more updates
Source_Retry_Count: 10
Source_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Source_SSL_Crl:
Source_SSL_Crlpath:
Retrieved_Gtid_Set: 73f86016-978b-11ee-ade5-8d2a2a562feb:1-3
Executed_Gtid_Set: 73f86016-978b-11ee-ade5-8d2a2a562feb:1-3
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Source_TLS_Version:
Source_public_key_path:
Get_source_public_key: 0
Network_Namespace:
状态报告中要检查的关键字段包括：

Replica_IO_State： 的当前状态 副本。请参见第 10.14.5 节 “复制 I/O（接收器）线程状态”， 以及第 10.14.6 节 “复制 SQL 线程状态”，了解更多信息 信息。

Replica_IO_Running：I/O 是否 （receiver） 用于读取源二进制日志的线程是 运行。通常，除非您尚未开始复制或已使用 STOP REPLICA 显式停止它，否则应为 Yes。

Replica_SQL_Running：是否 SQL 用于在中继日志中执行事件的线程正在运行。如 对于 I/O 线程，这通常应该是 Yes。

Last_IO_Error， ： 最后的错误 由 I/O（接收方）和 SQL（应用者）线程注册 处理中继日志时。理想情况下，这些应该是空白的，表示没有错误。Last_SQL_Error

Seconds_Behind_Source：数量 复制 SQL（应用者）线程落后的秒数 处理源二进制日志。一个高数字（或增加 1） 表示副本无法及时从源头处理事件。

值为 0 通常可以解释为副本具有 赶上了源头，但在某些情况下 严格来说，这并不正确。例如，如果出现以下情况，则可能会发生这种情况 源和副本之间的网络连接已断开 但复制 I/O（接收方）线程尚未注意到这一点；也就是说，replica_net_timeout设定的时间段没有 然而过去了。Seconds_Behind_Source

也有可能瞬态值的 不能 反映情况准确。当复制 SQL（应用者） 线程已赶上 I/O，显示 0;但当复制 I/O（接收器）线程仍在排队时 5月举办新活动 显示较大的值，直到复制应用程序线程完成新事件的执行。这尤其可能发生 当事件具有旧时间戳时；在这种情况下，如果您在相对较短的时间内多次执行 SHOW REPLICA STATUS，您可能会看到以下内容 值在 0 和 a 之间反复来回变化。非常有价值的情况。Seconds_Behind_SourceSeconds_Behind_SourceSeconds_Behind_Source

几对字段提供了关于进度的信息 从源二进制日志中读取事件的副本，以及在 中继日志中处理它们的过程：

(Master_Log_file， ）： 中的坐标 源二进制日志，指示复制 I/O 的距离 （receiver）线程已从该日志中读取事件。Read_Master_Log_Pos

(Relay_Master_Log_File， ）： 中的坐标 源二进制日志，指示复制 SQL 的距离 （applier） 线程已执行从该日志接收的事件。Exec_Master_Log_Pos

(Relay_Log_File， ）： 中的坐标 副本中继日志，指示复制 SQL 的距离 （applier）线程已执行中继日志。这些 对应于前面的坐标，但表示 在副本中继日志坐标而不是源二进制文件中的日志坐标。Relay_Log_Pos

在源上，您可以检查已连接到副本的状态 使用 SHOW PROCESSLIST 进行检查正在运行的进程的列表。副本连接在字段中具有：Binlog DumpCommand

19.1.7.2 暂停复制副本上的复制

在MySQL复制环境中，可以使用STOP REPLICA和START REPLICA语句来控制复制进程。这两个命令允许你在复制副本上暂停和恢复复制活动。

停止复制：
要停止处理来自源的二进制日志，执行以下命令：

STOP REPLICA;

这将导致复制I/O线程停止从源的二进制日志中读取事件并将其写入中继日志，同时SQL线程也会停止从中继日志读取事件并执行它们。

如果你想要单独暂停I/O线程或SQL线程，可以指定线程类型：

STOP REPLICA IO_THREAD;
STOP REPLICA SQL_THREAD;

启动复制：
若要重新开始复制过程，使用以下命令：

START REPLICA;

你也可以选择只启动特定的线程：

START REPLICA IO_THREAD;
START REPLICA SQL_THREAD;

在某些情况下，例如当你需要对副本执行备份或其他任务时，仅停止SQL线程而保持I/O线程运行可能是有用的。这样做可以让副本在不执行更新的情况下继续接收事件，从而更容易在重新启动SQL线程后赶上进度。

另一方面，如果仅停止I/O线程，则应用（SQL）线程会继续执行直到中继日志结束的位置。这在你希望暂停副本上的事件执行以等待已接收的事件得到处理时很有用，同时也确保了副本已处理所有更新到某个具体点。此方法还有助于在副本上执行管理操作时暂停事件处理，同时保证在再次启动复制时不会有大量积压的事件需要执行。

19.1.7.3 跳过事务

在处理复制过程中遇到的失败事务时，您可以通过以下步骤进行恢复：

1. 确定错误来源：首先，需要识别导致复制失败的具体原因。您可以检查性能架构表replication_applier_status_by_worker中记录的错误信息以及上次成功应用的事务详情。使用mysqlbinlog工具或通过查看RELAYLOG事件和SHOW BINLOG EVENTS来诊断错误。

2. 评估安全影响：在跳过任何事务之前，考虑是否涉及不受信任的来源或是否有其他安全注意事项，这可能影响是否应继续复制过程。

3. 选择适当的恢复方法：

   • 如果使用GTID（即gtid_mode=ON），请参考Section 19.1.7.3.1，“Skipping Transactions With GTID”。
   • 当未使用GTID或正在逐步实施时（即gtid_mode为OFF、OFF_PERMISSIVE或ON_PERMISSIVE），请参考Section 19.1.7.3.2，“跳过没有GTID的事务”。

4. 跳过事务后的操作：

   • 如果使用了GTID，在跳过事务后，可以通过发出START REPLICA命令（对于多源副本，使用FOR CHANNEL子句）来重新启动复制。
   • 如果没有使用GTID，您可能需要使用CHANGE REPLICATION SOURCE TO语句来更新复制设置，并指定正确的源二进制日志位置，然后重新启动复制。

5. 考虑清除二进制日志：如果副本上启用了二进制日志记录，并且空事务被记录到复制流中，可以考虑清除副本的二进制日志以防止将来的问题。

6. 监控和维护：在恢复复制后，持续监控复制状态以确保一切正常运行，并对可能出现的任何新问题保持警觉。

通过遵循这些步骤，您可以有效地处理复制过程中的失败事务，并确保复制环境的稳定和数据一致性。