为 Aurora MySQL 设置二进制日志复制 - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

为 Aurora MySQL 设置二进制日志复制

设置使用 Aurora MySQL 进行 MySQL 复制包括以下步骤(下面将详细讨论):

1. 在复制源上开启二进制日志记录

在下面查找有关如何在数据库引擎的复制源上开启二进制日志记录的说明。

2. 在复制源上保留二进制日志,直到不再需要

使用 MySQL 二进制日志复制时,Amazon RDS 不会对复制过程进行管理。因此,您需要确保复制源上的二进制日志文件保留到更改应用于副本之后。保留这些文件有助于在发生故障时可还原您的源数据库。

使用以下说明为数据库引擎保留二进制日志。

3. 创建复制源的副本或转储

使用复制源的快照、克隆或转储将数据的基准副本加载到您的副本。然后从该点开始复制。

使用以下说明创建数据库引擎的复制源的副本或转储。

4. 将转储加载到副本目标(如果需要)

如果您打算从 Amazon RDS 外部的 MySQL 数据库转储加载数据,则可能要创建用于将转储文件复制到其中的 EC2 实例。然后,可以从该 EC2 实例将数据加载到数据库集群或数据库实例中。使用此方法时,您可以在将转储文件复制到 EC2 实例之前压缩它们,以便降低与向 Amazon RDS 复制数据关联的网络成本。在网络中进行传输时,还可以加密转储文件以保护数据。

注意

如果您创建一个新的 Aurora MySQL 数据库集群作为副本目标,则不需要加载转储文件:

使用以下说明将复制源的转储加载到数据库引擎的副本目标中。

5. 在您的复制源上创建复制用户

在源上创建一个专用于复制的用户 ID。以下示例适用于 RDS for MySQL 或外部 MySQL 源数据库。

mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password';

对于 Aurora MySQL 源数据库,skip_name_resolve 数据库集群参数设置为 1ON)且无法修改,因此您必须使用主机的 IP 地址而不是域名。有关更多信息,请参阅 MySQL 文档中的 skip_name_resolve

mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password';

该用户需要 REPLICATION CLIENTREPLICATION SLAVE 权限。向该用户授予这些权限。

如果您需要使用加密复制,则需为复制用户要求 SSL 连接。例如,您可以使用下面的语句之一来要求对用户账户 repl_user 使用 SSL 连接。

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address';
GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL;
注意

如果不包括 REQUIRE SSL,则复制连接可能会无提示地返回到未加密连接。

6. 在副本目标上开启复制

开启复制之前,建议您手动创建 Aurora MySQL 数据库集群或 RDS for MySQL 数据库实例副本目标的快照。如果出现问题,而您需要重新建立与数据库集群或数据库实例副本目标间的复制,则您可以从此快照还原数据库集群或数据库实例,而不必再次将数据导入您的副本目标之中。

使用以下说明对数据库引擎开启复制。

如果复制失败,可能会导致副本上的意外输入/输出大量增加,从而降低性能。如果复制失败或不再需要复制,则可运行 mysql.rds_reset_external_master(Aurora MySQL 版本 2)mysql.rds_reset_external_source(Aurora MySQL 版本 3) 存储过程来删除复制配置。

设置停止复制到只读副本的位置

在 Aurora MySQL 版本 3.04 及更高版本中,您可以使用 mysql.rds_start_replication_until(Aurora MySQL 版本 3) 存储过程启动复制,然后在指定的二进制日志文件位置停止复制。

开始复制到只读副本并在特定位置处停止复制
  1. 通过使用 MySQL 客户端,以主用户的身份连接到副本 Aurora MySQL 数据库集群。

  2. 运行 mysql.rds_start_replication_until(Aurora MySQL 版本 3) 存储过程。

    以下示例将启动复制并复制更改,直到它到达 120 二进制日志文件中的 mysql-bin-changelog.000777 位置。在灾难恢复方案中,假定位置 120 刚好位于灾难之前。

    call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120);

当到达停止点时,复制将自动停止。将生成以下 RDS 事件:Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure

如果使用基于 GTID 的复制,请使用 mysql.rds_start_replication_until_gtid(Aurora MySQL 版本 3) 存储过程而不是 mysql.rds_start_replication_until(Aurora MySQL 版本 3) 存储过程。有关基于 GTID 的复制的更多信息,请参阅使用基于 GTID 的复制

7. 监控副本

在设置与 Aurora MySQL 数据库集群的 MySQL 复制时,您必须在 Aurora MySQL 数据库集群作为副本目标时监控它的失效转移事件。如果发生失效转移,则可能会在具有不同网络地址的新主机上重新创建作为副本目标的数据库集群。有关如何监控失效转移事件的信息,请参阅使用 Amazon RDS 事件通知

您还可以通过连接到副本目标并运行 SHOW SLAVE STATUS(Aurora MySQL 版本 2)或 SHOW REPLICA STATUS(Aurora MySQL 版本 3)命令,监控副本目标落后于复制源的程度。命令输出中的 Seconds Behind Master 字段可以揭示副本目标落后于源的程度。

重要

如果您升级数据库集群并指定自定义参数组,请确保在升级完成后手动重启集群。这样可以让集群使用新的自定义参数设置,并重新启动二进制日志复制。

在复制源和目标之间同步密码

使用 SQL 语句更改复制源上的用户账户和密码时,这些更改将自动复制到复制目标。

如果您使用 Amazon Web Services Management Console、Amazon CLI 或 RDS API 来更改复制源上的主密码,则这些更改不会自动复制到复制目标。如果要在源系统和目标系统之间同步主用户和主密码,则必须自己对复制目标进行相同的更改。