Skip to main content

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

本节介绍如何设置 MySQL 服务器以使用基于二进制日志文件位置的复制。设置复制有多种不同的方法,具体使用的方法取决于设置复制的方式,以及想要复制的源上的数据库中是否已有数据。

提示:

要部署多个 MySQL 实例,可以使用InnoDB Cluster ,它使能够在MySQL Shell中轻松管理一组 MySQL 服务器实例。InnoDB Cluster 将 MySQL 组复制封装在编程环境中,能够轻松部署 MySQL 实例集群以实现高可用性。此外,InnoDB Cluster 与MySQL Router无缝对接,使应用程序无需编写自己的故障转移过程即可连接到集群。

但是,对于不需要高可用性的类似用例,可以使用InnoDB ReplicaSet。可在此处找到 MySQL Shell 的安装说明。

有一些所有设置都通用的通用任务:

  • 在源上,必须确保启用二进制日志记录,并配置唯一的服务器 ID。这可能需要重新启动服务器。
  • 在要连接到源的每个副本上,必须配置唯一的服务器 ID。这可能需要重新启动服务器。
  • 或者,为副本创建一个单独的用户,以便在读取二进制日志进行复制时与源进行身份验证期间使用。
  • 在创建数据快照或开始复制过程之前,应该在源上记录二进制日志中的当前位置。配置副本时需要此信息,以便副本知道二进制日志中的何处开始执行事件。
  • 如果源上已经有数据并希望使用它来同步副本,则需要创建数据快照以将数据复制到副本。使用的存储引擎会影响创建快照的方式。当使用 时MyISAM,必须停止处理源上的语句以获取读锁,然后获取其当前的二进制日志坐标并转储其数据,然后才允许源继续执行语句。如果不停止语句的执行,数据转储和源状态信息将变得不匹配,从而导致副本上的数据库不一致或损坏。如果使用InnoDB,则不需要读锁,并且足够长的事务来传输数据快照就足够了。
  • 使用连接到源的设置配置副本,例如主机名、登录凭据以及二进制日志文件名和位置。
  • 根据系统,在源和副本上实施特定于复制的安全措施。

提示:

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

配置基本选项后,选择场景:

  • 要为不包含数据的源和副本的全新安装设置复制,请参阅文章:“使用新源和副本设置复制”。
  • 要使用现有 MySQL 服务器中的数据设置新源的复制,请参阅文章:“使用现有数据设置复制”。
  • 要将副本添加到现有复制环境,请参阅文章:“将副本添加到复制环境”。

在管理 MySQL 复制服务器之前,请阅读整章并尝试“用于控制源服务器的 SQL 语句”和 “用于控制副本服务器的 SQL 语句”文章中提到的所有语句。还要熟悉“复制和二进制日志记录选项和变量”文章中描述的复制启动选项。

设置复制源配置

要将源配置为使用基于二进制日志文件位置的复制,必须确保启用二进制日志记录,并建立唯一的服务器 ID。

复制拓扑中的每个服务器都必须配置唯一的服务器 ID,可以使用 server_id 系统变量指定该 ID。 此服务器 ID 用于标识复制拓扑中的各个服务器,并且必须是 1 到 (232)−1 之间的正整数。 默认server_id值为1; 可以在运行时通过发出如下语句来更改此设置:

SET GLOBAL server_id = 2;

服务器 ID 的组织和选择是任意的,只要每个服务器 ID 与复制拓扑中任何其他服务器使用的每个其他服务器 ID 不同即可。 请注意,如果之前将服务器 ID 设置为 0 值,则必须重新启动服务器才能使用新的非零服务器 ID 初始化源。 否则,更改服务器 ID 时不需要重新启动服务器,除非进行其他需要重新启动的配置更改。

源上需要二进制日志记录,因为二进制日志是将更改从源复制到其副本的基础。 默认情况下启用二进制日志记录(log_bin 系统变量设置为 ON)。 --log-bin 选项告诉服务器二进制日志文件使用什么基本名称。 建议指定此选项来为二进制日志文件指定一个非默认的基本名称,这样,如果主机名发生更改,可以轻松地继续使用相同的二进制日志文件名。 如果之前使用 --skip-log-bin 选项在源上禁用了二进制日志记录,则必须在不使用此选项的情况下重新启动服务器才能启用它。

注意:

以下选项也会对源产生影响:

为了在使用 InnoDB 和事务的复制设置中获得最大可能的持久性和一致性,应该在源的 my.cnf 文件中使用 innodb_flush_log_at_trx_commit=1 和sync_binlog=1。

确保源上未启用skip_networking 系统变量。 如果网络已禁用,副本将无法与源通信,并且复制会失败。

设置副本配置

每个副本必须有一个唯一的服务器 ID,由 server_id 系统变量指定。 如果要设置多个副本,则每个副本都必须具有唯一的 server_id 值,该值不同于源的值以及任何其他副本的值。 如果尚未设置副本的服务器 ID,或者当前值与源或其他副本选择的值冲突,则必须更改它。

默认 server_id 值为 1。可以通过发出如下语句来动态更改 server_id 值:

SET GLOBAL server_id = 21;

请注意,服务器 ID 值为 0 会阻止副本连接到源。 如果之前设置了该服务器 ID 值(这是早期版本中的默认值),则必须重新启动服务器才能使用新的非零服务器 ID 初始化副本。 否则,更改服务器 ID 时不需要重新启动服务器,除非进行其他需要重新启动的配置更改。 例如,如果服务器上禁用了二进制日志记录,而希望为副本启用它,则需要重新启动服务器才能启用此功能。

如果要关闭副本服务器,可以编辑配置文件的 [mysqld] 部分来指定唯一的服务器 ID。 例如:

[mysqld]
server-id=21

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

A -> B -> C

此处,A 充当副本 B 的源,B 充当副本 C 的源。为此,B 必须既是源又是副本。 从 A 接收到的更新必须由 B 记录到其二进制日志中,以便传递到 C。除了二进制日志记录之外,此复制拓扑还需要启用系统变量 log_replica_updates。 启用副本更新后,副本将从源接收并由副本的 SQL 线程执行的更新写入副本自己的二进制日志。 log_replica_updates 默认启用。

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

创建用于复制的用户

每个副本都使用 MySQL 用户名和密码连接到源,因此源上必须有一个副本可以用来连接的用户帐户。 设置副本时,用户名由 CHANGE REPLICATION SOURCE TO 语句的 SOURCE_USER 选项指定。 任何帐户都可以用于此操作,只要已被授予 REPLICATION SLAVE 权限。 可以选择为每个副本创建不同的帐户,或为每个副本使用相同的帐户连接到源。

尽管不必专门为复制创建帐户,但应该注意,复制用户名和密码以纯文本形式存储在副本的连接元数据存储库 mysql.slave_master_info 中。 因此,可能需要创建一个仅具有复制过程权限的单独帐户,以最大程度地减少其他帐户受到损害的可能性。

要创建新帐户,请使用 CREATE USER。 要授予此帐户复制所需的权限,请使用 GRANT 语句。 如果仅出于复制目的创建帐户,则该帐户仅需要 REPLICATION SLAVE 权限。 例如,要设置一个新用户 repl,该用户可以从 example.com 域内的任何主机进行连接以进行复制,请在源上发出以下语句:

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

有关操纵用户帐户的语句的更多信息,请参阅文章:“帐户管理语句”。

注意:

要使用通过 caching_sha2_password 插件进行身份验证的用户帐户连接到源,必须按照文章:“设置复制以使用加密连接”中所述设置安全连接,或者启用未加密连接以支持密码 使用 RSA 密钥对进行交换。 caching_sha2_password 身份验证插件是新用户的默认插件。 如果创建或用于复制的用户帐户(由 SOURCE_USER 选项指定)使用此身份验证插件,并且没有使用安全连接,则必须启用基于 RSA 密钥对的密码交换才能成功连接。

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

要配置副本以在正确的点启动复制过程,需要记下源在其二进制日志中的当前坐标。

注意:

此过程使用 FLUSH TABLES WITH READ LOCK,它会阻止 InnoDB 表的 COMMIT 操作。

如果计划关闭源来创建数据快照,可以选择跳过此过程,而是将二进制日志索引文件的副本与数据快照一起存储。 在这种情况下,源会在重新启动时创建一个新的二进制日志文件。 因此,副本必须开始复制过程的源二进制日志坐标是该新文件的开始,该新文件是源上紧随复制的二进制日志索引文件中列出的文件之后的下一个二进制日志文件。

要获取源二进制日志坐标,请执行以下步骤:

  • 通过使用命令行客户端连接到源来启动源上的会话,并通过执行 FLUSH TABLES WITH READ LOCK 语句来刷新所有表并阻止写入语句:

    mysql> FLUSH TABLES WITH READ LOCK;

    让发出 FLUSH TABLES 语句的客户端保持运行状态,以便读锁保持有效。 如果退出客户端,锁就会被释放。

  • 在源上的不同会话中,使用 SHOW BINARY LOG STATUS 语句确定当前二进制日志文件名和位置:

    mysql> SHOW BINARY LOG STATUS\G
    *************************** 1. row ***************************
    File: mysql-bin.000003
    Position: 73
    Binlog_Do_DB: test
    Binlog_Ignore_DB: manual, mysql
    Executed_Gtid_Set: 3E11FA47-71CA-11E1-9E33-C80AA9429562:1-5
    1 row in set (0.00 sec)

    文件列显示日志文件的名称,位置列显示文件内的位置。 在本例中,二进制日志文件为 mysql-bin.000003,位置为 73。记录这些值。 稍后在设置副本时需要它们。 它们表示副本应开始处理来自源的新更新的复制坐标。

    如果源之前已在禁用二进制日志记录的情况下运行,则 SHOW BINARY LOG STATUS 或 mysqldump --source-data 显示的日志文件名和位置值将为空。 在这种情况下,稍后在指定源的二进制日志文件和位置时需要使用的值为空字符串 ('') 和 4。

现在,已获得所需的信息,使副本能够在正确的位置开始从源的二进制日志中读取以开始复制。

下一步取决于源上的现有数据。 选择以下选项之一:

  • 如果在开始复制之前有需要与副本同步的现有数据,请让客户端保持运行状态,以便锁定保持不变。 这可以防止进行任何进一步的更改,以便复制到副本的数据与源同步。
  • 如果正在设置新的源和副本组合,则可以退出第一个会话以释放读锁。 有关如何继续操作,请参阅文章:“使用新源和副本设置复制”。

选择数据快照的方法

如果源数据库包含现有数据,则需要将此数据复制到每个副本。 有多种方法可以从源数据库转储数据。 以下部分描述了可能的选项。

要选择转储数据库的适当方法,请在以下选项之间进行选择:

  • 使用 mysqldump 工具创建要复制的所有数据库的转储。 这是推荐的方法,尤其是在使用 InnoDB 时。
  • 如果数据库存储在二进制可移植文件中,可以将原始数据文件复制到副本。 这比使用 mysqldump 并在每个副本上导入文件更有效,因为它跳过了重播 INSERT 语句时更新索引的开销。 对于 InnoDB 等存储引擎,不建议这样做。
  • 使用 MySQL Server 的克隆插件将所有数据从现有副本传输到克隆。 有关使用此方法的说明,请参见文章“克隆以进行复制”。

使用 mysqldump 创建数据快照

要创建现有源数据库中数据的快照,请使用 mysqldump 工具。 数据转储完成后,请在开始复制过程之前将此数据导入副本。

以下示例将所有数据库转储到名为 dbdump.db 的文件,并包含 --source-data 选项,该选项自动附加副本上启动复制过程所需的 CHANGE REPLICATION SOURCE TO 语句:

$> mysqldump --all-databases --source-data > dbdump.db

注意:

如果不使用--source-data,则需要手动锁定单独会话中的所有表。

可以使用 mysqldump 工具从转储中排除某些数据库。 如果要选择转储中包含哪些数据库,请不要使用 --all-databases。 选择以下选项之一:

  • 使用 --ignore-table 选项排除数据库中的所有表。
  • 仅指定要使用 --databases 选项转储的数据库。

注意:

默认情况下,如果源上正在使用 GTID (gtid_mode=ON),则 mysqldump 会在转储输出中包含来自源上 gtid_execulated 集的 GTID,以将它们添加到副本上的 gtid_purged 集中。 如果仅转储特定数据库或表,请务必注意,mysqldump 包含的值包括源上 gtid_execulated 集中所有事务的 GTID,甚至是那些更改了数据库或其他数据库的受抑制部分的事务 在未包含在部分转储中的服务器上。 检查 mysqldump 的 --set-gtid-purged 选项的描述,以查找正在使用的 MySQL Server 版本的默认行为的结果,以及如果此结果不适合情况如何更改该行为。

要导入数据,请将转储文件复制到副本,或者在远程连接到副本时从源访问该文件。

使用原始数据文件创建数据快照

本节介绍如何使用构成数据库的原始文件创建数据快照。 将此方法与使用具有复杂缓存或日志记录算法的存储引擎的表一起使用需要额外的步骤来生成完美的“时间点”快照:初始复制命令可能会遗漏缓存信息和日志记录更新,即使已经获取了 全局读锁。 存储引擎如何响应取决于其崩溃恢复能力。

如果使用 InnoDB 表,则可以使用 MySQL Enterprise Backup 组件中的 mysqlbackup 命令来生成一致的快照。 此命令记录与要在副本上使用的快照对应的日志名称和偏移量。 MySQL Enterprise Backup 是一款商业产品,作为 MySQL Enterprise 订阅的一部分包含在内。 有关详细信息,请参阅官网文档:“MySQL 企业备份概述”。

如果源和副本具有不同的 ft_stopword_file、ft_min_word_len 或 ft_max_word_len 值,并且正在复制具有全文索引的表,则此方法也无法可靠地工作。

假设上述例外情况不适用于的数据库,请使用冷备份技术来获取 InnoDB 表的可靠二进制快照:缓慢关闭 MySQL 服务器,然后手动复制数据文件。

当 MySQL 数据文件存在于单个文件系统上时,要创建 MyISAM 表的原始数据快照,可以使用标准文件复制工具(如 cp 或 copy)、远程复制工具(如 scp 或 rsync)、归档工具(如 zip) 或 tar,或文件系统快照工具,例如 dump。 如果仅复制某些数据库,则仅复制与这些表相关的文件。 对于 InnoDB,所有数据库中的所有表都存储在系统表空间文件中,除非启用了 innodb_file_per_table 选项。

复制不需要以下文件:

  • 与mysql数据库相关的文件。
  • 副本的连接元数据存储库文件 master.info(如果使用); 现在不推荐使用此文件。
  • 源的二进制日志文件,但二进制日志索引文件除外(如果要使用它来定位副本的源二进制日志坐标)。
  • 任何中继日志文件。

根据是否使用 InnoDB 表,选择以下选项之一:

如果使用的是 InnoDB 表,并且为了获得与原始数据快照最一致的结果,请在此过程中关闭源服务器,如下所示:

  • 获取读锁并获取源的状态。

  • 在单独的会话中,关闭源服务器:

    $> mysqladmin shutdown
  • 制作 MySQL 数据文件的副本。 以下示例显示了执行此操作的常见方法。 只需选择其中之一:

    $> tar cf /tmp/db.tar ./data
    $> zip -r /tmp/db.zip ./data
    $> rsync --recursive ./data /tmp/dbdata
  • 重新启动源服务器。

创建数据库的存档或副本后,请在开始复制过程之前将文件复制到每个副本。

设置副本

以下部分描述如何设置副本。 在继续之前,请确保拥有:

  • 使用必要的配置属性配置源。

  • 获取源状态信息,或在数据快照关闭期间创建的源二进制日志索引文件的副本。

  • 在源上,释放读锁:

    mysql> UNLOCK TABLES;
  • 在副本上,编辑 MySQL 配置。

接下来的步骤取决于是否有现有数据要导入到副本。 选择以下选项之一:

  • 如果没有要导入的数据库快照,请参见文章:“使用新源和副本设置复制”。
  • 如果有要导入的数据库快照,请参见文章:“使用现有数据设置复制”。

使用新源和副本设置复制

当没有要导入的先前数据库的快照时,将副本配置为从新源开始复制。

要设置源和新副本之间的复制:

启动副本。

在副本上执行 CHANGE REPLICATION SOURCE TO 语句以设置源配置。

在每个副本上执行这些副本设置步骤。

  • 如果要设置新服务器,但有来自其他服务器的现有数据库转储,并且想要将其加载到复制配置中,也可以使用此方法。 通过将数据加载到新的源中,数据会自动复制到副本。

  • 如果要使用来自不同现有数据库服务器的数据来设置新的复制环境来创建新源,请在新源上运行从该服务器生成的转储文件。 数据库更新会自动传播到副本:

    $> mysql -h source < fulldb.dump

设置与现有数据的复制

使用现有数据设置复制时,请在开始复制之前将快照从源传输到副本。 将数据导入副本的过程取决于在源上创建数据快照的方式。

注意:

如果要复制以创建新副本的复制源服务器或现有副本有任何计划事件,请确保在启动新副本之前禁用这些事件。 如果事件在已在源上运行的新副本上运行,则重复的操作会导致错误。 事件调度程序由 event_scheduler 系统变量(默认为 ON)控制,因此在新副本启动时默认运行原始服务器上活动的事件。 要停止所有事件在新副本上运行,请在新副本上将 event_scheduler 系统变量设置为 OFF 或 DISABLED。 或者,可以使用 ALTER EVENT 语句将各个事件设置为 DISABLE 或 DISABLE ON REPLICA,以防止它们在新副本上运行。 可以使用 SHOW 语句或信息架构事件表列出服务器上的事件。

作为以这种方式创建新副本的替代方法,MySQL Server 的克隆插件可用于将所有数据和复制设置从现有副本传输到克隆。 有关使用此方法的说明,请参见文章: “克隆以进行复制”。

请按照以下过程设置与现有数据的复制:

  1. 如果使用 MySQL Server 的克隆插件从现有副本创建克隆,则数据已传输。 否则,请使用以下方法之一将数据导入到副本。
    • 如果使用了 mysqldump,请启动副本服务器,并通过使用 --skip-replica-start 启动服务器来确保复制不会启动。 然后导入转储文件:

      $> mysql < fulldb.dump
    • 如果使用原始数据文件创建了快照,请将数据文件提取到副本的数据目录中。 例如:

      $> tar xvf dbdump.tar

      可能需要设置文件的权限和所有权,以便副本服务器可以访问和修改它们。 然后启动副本服务器,确保使用 --skip-replica-start 不会启动复制。

  2. 使用来自源的复制坐标配置副本。 这告诉副本二进制日志文件以及文件中复制需要开始的位置。 另外,使用源的登录凭据和主机名配置副本。
  3. 通过发出 START REPLICA 语句来启动复制线程。

执行此过程后,副本将连接到源并复制自拍摄快照以来源上发生的任何更新。 如果副本因任何原因无法复制,则会向副本的错误日志发出错误消息。

副本使用其连接元数据存储库和应用程序元数据存储库中记录的信息来跟踪其已处理的源二进制日志量。 默认情况下,这些存储库是mysql数据库中名为slave_master_info和slave_relay_log_info的表。 除非确切知道自己在做什么并完全理解其含义,否则请勿删除或编辑这些表。 即使在这种情况下,也最好使用 CHANGE REPLICATION SOURCE TO 语句来更改复制参数。 副本使用语句中指定的值自动更新复制元数据存储库。

提示:

副本的连接元数据存储库的内容会覆盖在命令行或 my.cnf 中指定的某些服务器选项。

源的单个快照足以满足多个副本的需要。 要设置其他副本,请使用相同的源快照并按照刚才描述的过程的副本部分进行操作。

在副本上设置源配置

要设置副本以与源进行通信以进行复制,请为副本配置必要的连接信息。 为此,在副本上执行以下 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 设置安全复制。 有关选项的完整列表以及有关字符串值选项的最大允许长度的信息,请参阅第文章:“CHANGE REPLICATION SOURCE TO Statement”。

注意:

如果没有使用安全连接,并且 SOURCE_USER 选项中指定的用户帐户使用 caching_sha2_password 插件(MySQL 8.3 中的默认值)进行身份验证,则必须指定 CHANGE REPLICATION SOURCE TO 语句中的 SOURCE_PUBLIC_KEY_PATH 或 GET_SOURCE_PUBLIC_KEY 选项可启用基于 RSA 密钥对的密码交换。

将副本添加到复制环境

可以将另一个副本添加到现有复制配置,而无需停止源服务器。 为此,可以通过复制现有副本的数据目录并为新副本指定不同的服务器 ID(用户指定)和服务器 UUID(在启动时生成)来设置新副本。

注意:

如果要复制以创建新副本的复制源服务器或现有副本有任何计划事件,请确保在启动新副本之前禁用这些事件。 如果事件在已在源上运行的新副本上运行,则重复的操作会导致错误。 事件计划程序由 event_scheduler 系统变量控制,该变量默认为 ON,因此在新副本启动时默认运行原始服务器上活动的事件。 要停止所有事件在新副本上运行,请在新副本上将 event_scheduler 系统变量设置为 OFF 或 DISABLED。 或者,可以使用 ALTER EVENT 语句将各个事件设置为 DISABLE 或 DISABLE ON REPLICA,以防止它们在新副本上运行。 可以使用 SHOW 语句或信息架构事件表列出服务器上的事件。

作为以这种方式创建新副本的替代方法,MySQL Server 的克隆插件可用于将所有数据和复制设置从现有副本传输到克隆。

要复制现有副本而不进行克隆,请执行以下步骤:

  1. 停止现有副本并记录副本状态信息,特别是源二进制日志文件和中继日志文件位置。 可以在性能模式复制表中查看副本状态,也可以通过发出 SHOW REPLICA STATUS 来查看副本状态,如下所示:

    mysql> STOP REPLICA;
    mysql> SHOW REPLICA STATUS\G
  2. 关闭现有副本:

    $> mysqladmin shutdownd
  3. 将数据目录从现有副本复制到新副本,包括日志文件和中继日志文件。 可以通过使用 tar 或 WinZip 创建存档,或者使用 cp 或 rsync 等工具执行直接复制来完成此操作。

    重要:

    在复制之前,请验证与现有副本相关的所有文件是否确实存储在数据目录中。 例如,InnoDB 系统表空间、撤消表空间和重做日志可能存储在备用位置。 InnoDB 表空间文件和每表文件表空间可能已在其他目录中创建。 副本的二进制日志和中继日志可能位于数据目录之外的自己的目录中。 检查为现有副本设置的系统变量,并查找已指定的任何替代路径。 如果找到任何目录,也将这些目录复制过来。

    在复制过程中,如果文件已用于复制元数据存储库,请确保还将这些文件从现有副本复制到新副本。 如果表已用于存储库(默认情况下,表位于数据目录中)。

    复制后,从新副本上的数据目录副本中删除 auto.cnf 文件,以便新副本以不同的生成的服务器 UUID 启动。 服务器 UUID 必须是唯一的。

    添加新副本时遇到的一个常见问题是新副本失败并显示一系列警告和错误消息,如下所示:

       071118 16:44:10 [Warning] Neither --relay-log nor --relay-log-index were used; so
    replication may break when this MySQL server acts as a replica and has his hostname
    changed!! Please use '--relay-log=new_replica_hostname-relay-bin' to avoid this problem.
    071118 16:44:10 [ERROR] Failed to open the relay log './old_replica_hostname-relay-bin.003525'
    (relay_log_pos 22940879)
    071118 16:44:10 [ERROR] Could not find target log during relay log initialization
    071118 16:44:10 [ERROR] Failed to initialize the master info structure

    如果未指定relay_log 系统变量,则可能会出现这种情况,因为中继日志文件包含主机名作为其文件名的一部分。 如果不使用relay_log_index系统变量,中继日志索引文件也是如此。 要避免此问题,请在新副本上使用与现有副本上使用的相同的值。 如果未在现有副本上显式设置此选项,请使用existing_replica_hostname-relay-bin。 如果这不可能,请将现有副本的中继日志索引文件复制到新副本,并在新副本上设置relay_log_index 系统变量以匹配现有副本上使用的内容。 如果未在现有副本上显式设置此选项,请使用existing_replica_hostname-relay-bin.index。 或者,如果在执行本节中的其余步骤后已尝试启动新副本,并且遇到了类似前面所述的错误,则执行以下步骤:

    • 如果尚未执行此操作,请在新副本上发出 STOP REPLICA。如果已再次启动现有副本,请也在现有副本上发出 STOP REPLICA。
    • 将现有副本的中继日志索引文件的内容复制到新副本的中继日志索引文件中,确保覆盖文件中已有的任何内容。
    • 继续执行本节中的其余步骤。
  4. 复制完成后,重新启动现有副本。

  5. 在新副本上,编辑配置并为新副本提供一个唯一的服务器 ID(使用 server_id 系统变量),该 ID 不被源或任何现有副本使用。

  6. 启动新的副本服务器,通过指定 --skip-replica-start 确保复制尚未开始。 使用性能架构复制表或发出 SHOW REPLICA STATUS 来确认新副本与现有副本相比具有正确的设置。 还显示服务器 ID 和服务器 UUID,并验证这些对于新副本来说是否正确且唯一。

  7. 通过发出 START REPLICA 语句来启动副本线程。 新副本现在使用其连接元数据存储库中的信息来启动复制过程。