使用 Amazon Aurora MySQL 进行单主复制 - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

使用 Amazon Aurora MySQL 进行单主复制

Aurora MySQL 复制功能是提高集群可用性与性能的关键所在。Aurora 可以帮助您轻松创建集群并调整大小(最多可创建 15 个 Aurora 副本)。

所有副本采用相同的基础数据。如果某些数据库实例离线,其他处于可用状态的数据库实例将继续处理查询,或者在需要时作为写入器接管这些实例。Aurora 会自动将您的只读连接分配到多个数据库实例中,从而帮助 Aurora 集群更好地支持查询密集型工作负载。

在下文中,您可以了解 Aurora MySQL 复制的工作方式以及如何微调复制设置以获得最佳的可用性和性能。

注意

接下来,您可以了解使用单主复制的 Aurora 集群的复制功能。这种集群是 Aurora 的默认设置。有关 Aurora 多主集群的信息,请参阅 使用 Aurora 多主集群

使用 Aurora 副本

Aurora 副本是 Aurora 数据库集群中的独立终端节点,最适合用于扩展读取操作以及提高可用性。对于数据库集群在Amazon区域中所跨的多个可用区,最多可以分配 15 个 Aurora 副本。虽然数据库集群卷由数据库集群的多个数据副本组成,但集群卷中的数据表示为数据库集群中的主实例和 Aurora 副本的单个逻辑卷。有关 Aurora 副本的更多信息,请参阅 Aurora 副本

Aurora 副本十分适用于读取扩展,因为它们完全专用于集群卷上的读取操作。写入操作由主实例进行管理。由于集群卷是在 Aurora MySQL 数据库集群中的所有实例之间共享的,因此,无需执行额外的操作以复制每个 Aurora 副本的数据副本。相比之下,MySQL 只读副本必须在单一线程上,重放从源数据库实例向其本地数据存储的所有写入操作。此限制会影响到 MySQL 只读副本支持海量读取流量的能力。

对于 Aurora MySQL,在删除 Aurora 副本时,将立即删除其实例终端节点,并将 Aurora 副本从读取器终端节点中删除。如果在正待删除的 Aurora 副本上运行语句,则有 3 分钟宽限期。现有语句可在此宽限期内正常完成。当此宽限期结束后,将关闭并删除 Aurora 副本。

重要

对于在 InnoDB 表上执行的操作,Aurora MySQL 的 Aurora 副本始终使用 REPEATABLE READ 默认事务隔离级别。仅对于 Aurora MySQL 数据库集群的主实例,您可以使用 SET TRANSACTION ISOLATION LEVEL 命令更改事务级别。该限制避免在 Aurora 副本上出现用户级锁定,并允许 Aurora 副本扩展以支持数千个活动用户连接,同时仍保持最小的副本滞后时间。

注意

在主实例上运行的 DDL 语句可能会中断关联的 Aurora 副本上的数据库连接。如果 Aurora 副本连接主动使用数据库对象(如表),并且使用 DDL 语句在主实例上修改该对象,则会中断 Aurora 副本连接。

注意

中国 (宁夏) 区域不支持跨区域只读副本。

Amazon Aurora MySQL 的复制选项

您可以在以下任意选项之间设置复制:

注意

重新引导 Amazon Aurora 数据库集群的主实例还会自动重新引导该数据库集群的 Aurora 副本,以便重新建立入口点来确保数据库集群中的读/写一致性。

Amazon Aurora MySQL 复制的性能注意事项

以下功能可以帮助您微调 Aurora MySQL 复制性能。

从 Aurora MySQL 1.17.4 开始,副本日志压缩功能自动降低复制消息的网络带宽。由于每条消息将传输到所有 Aurora 副本,因此,较大的集群的好处更大。该功能在写入方节点上产生一些 CPU 开销以执行压缩。因此,该功能仅适用于具有较高 CPU 容量的 8xlarge16xlarge 实例类。默认情况下,将在这些实例类上启用该功能。您可以禁用 aurora_enable_replica_log_compression 参数以控制该功能。例如,如果写入方节点接近最大 CPU 容量,您可能会为较大的实例类禁用副本日志压缩。

从 Aurora MySQL 1.17.4 开始,二进制日志筛选功能自动降低复制消息的网络带宽。由于 Aurora 副本不使用复制消息中包含的二进制日志信息,因此,将从发送到这些节点的消息中省略该数据。您可以更改 aurora_enable_repl_bin_log_filtering 参数以控制该功能。默认情况下,该参数为 on。由于该优化应该是透明的,因此,您只能在诊断或故障排除期间禁用该设置以解决与复制相关的问题。例如,与无法使用该功能的旧 Aurora MySQL 集群的行为相符。

Amazon Aurora MySQL 的零停机重启 (ZDR)

零停机重启 (ZDR) 功能可以在某些类型的重启期间保留与数据库实例的部分或全部活动连接。ZDR 适用于 Aurora 自动执行以解决错误条件的重启,例如,当副本开始远远落后于源时。

重要

ZDR 机制运作以尽力而为作为原则。Aurora MySQL 版本、实例类、错误条件、兼容的 SQL 操作以及确定 ZDR 应用位置的其他因素随时可能会发生变化。

在提供 ZDR 的 Aurora MySQL 1.* 版本中,您可以通过开启集群参数组中的 aurora_enable_zdr 参数来开启此功能。Aurora MySQL 2.* 的 ZDR 需要版本 2.10 及更高版本。ZDR 在 Aurora MySQL 3.* 的所有次要版本中都可用。在 Aurora MySQL 版本 2 和 3 中,ZDR 机制原定设置处于开启状态,且 Aurora 不使用 aurora_enable_zdr 参数。

Aurora 会在 Event(事件) 页面中报告与零停机时间重新启动相关的活动。Aurora 在尝试使用 ZDR 机制重新启动时会记录一个事件。此事件说明了 Aurora 重启的原因。然后,在重启完成后,Aurora 会记录另一个事件。这最后一个事件报告了进程所用时长,以及在重启期间保留或丢弃的连接数。您可以查看数据库错误日志,了解有关重启期间所发生情况的更多详细信息。

尽管成功执行 ZDR 操作后连接保持不变,但一些变量和功能会重新初始化。通过零停机重启进行重启后,以下类型的信息将不会保留:

  • 全局变量。Aurora 将恢复会话变量,但重启后不会恢复全局变量。

  • 状态变量。特别是,引擎状态报告的正常运行时间值将重置。

  • LAST_INSERT_ID.

  • 表的内存中 auto_increment 状态。重新初始化内存中的自动增量状态。有关自动增量值的更多信息,请参阅 MySQL 参考手册

  • 来自 INFORMATION_SCHEMAPERFORMANCE_SCHEMA 表的诊断信息。这些诊断信息也会显示在 SHOW PROFILESHOW PROFILES 等命令的输出中。

下表显示了版本、实例角色、实例类以及确定在重启集群中的数据库实例时 Aurora 是否可以使用 ZDR 机制的其他情况。

Aurora MySQL version ZDR 适用于写入器吗? ZDR 适用于读取器吗? 备注

Aurora MySQL 版本 1.*,1.17.3 及更低版本

ZDR 不适用于这些版本。

Aurora MySQL 版本 1.*,1.17.4 及更高版本

在这些 Aurora MySQL 版本中,使用 ZDR 机制时,需注意以下情况:

  • 如果在数据库实例上开启了二进制日志记录,则 Aurora 不会使用 ZDR 机制。

  • Aurora 回滚活动连接上正在执行的所有事务。您的应用程序必须重试事务。

  • Aurora 取消任何使用 TLS/SSL、临时表、表锁定或用户锁定的连接。

Aurora MySQL 版本 2.*,2.10.0 之前的版本

ZDR 不适用于这些版本。Aurora MySQL 版本 2 的默认集群参数组中未提供 aurora_enable_zdr 参数。

Aurora MySQL 版本 2.*,2.10.0 及更高版本

ZDR 机制始终处于启用状态。

在这些 Aurora MySQL 版本中,使用 ZDR 机制时,需注意以下情况:

  • Aurora 回滚活动连接上正在执行的所有事务。您的应用程序必须重试事务。

  • Aurora 取消任何使用 TLS/SSL、临时表、表锁定或用户锁定的连接。

Aurora MySQL 版本 3.*

ZDR 机制始终处于启用状态。

同样的条件适用于 Aurora MySQL 版本 2.10。ZDR 适用于所有实例类。

监控 Amazon Aurora MySQL 复制

读取扩展和高可用性依赖于尽可能短的滞后时间。您可以通过监控 Amazon CloudWatch AuroraReplicaLag 指标来监控 Aurora 副本滞后于 Aurora MySQL 数据库集群主实例的时间。AuroraReplicaLag 指标记录在每个 Aurora 副本中。

主数据库实例还记录 AuroraReplicaLagMaximumAuroraReplicaLag Amazon CloudWatch 指标。AuroraReplicaLagMaximum 指标记录主数据库实例与数据库集群中每个 Aurora 副本之间的最大滞后量。AuroraReplicaLag 指标记录主数据库实例与数据库集群中每个 Aurora 副本之间的最小滞后量。

如果需要 Aurora 副本滞后的最新值,可在您的 Aurora MySQL 数据库集群中的主实例上查询 recrystallisations 表并查看 Replica_lag_in_msec 列中的值。此列值作为 AuroraReplicaLag 指标的值提供给 Amazon CloudWatch。Aurora 副本滞后也会记录在 Aurora MySQL 数据库集群中 INFORMATION_SCHEMA.REPLICA_HOST_STATUS 表中的每个 Aurora 副本上。

有关监控 RDS 实例和 CloudWatch 指标的更多信息,请参阅监控 Amazon Aurora 集群中的指标

Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制(二进制日志复制)

Amazon Aurora MySQL 与 MySQL 兼容,因此您可以在 MySQL 数据库与 Amazon Aurora MySQL 数据库集群之间设置复制。此类复制使用 MySQL 二进制日志复制,也称为二进制日志复制。如果将二进制日志复制与 Aurora 结合使用,建议您的 MySQL 数据库运行 MySQL 版本 5.5 或更高版本。您可以在 Aurora MySQL 数据库集群为复制源或副本的位置设置复制。您可以使用 Amazon RDS MySQL 数据库实例、Amazon RDS 外部的 MySQL 数据库或其他 Aurora MySQL 数据库集群进行复制。

注意

您不能使用二进制日志复制到某些类型的 Aurora 集群或从中复制。特别是,二进制日志复制不可用于 Aurora Serverless v1 和多主集群。如果 SHOW MASTER STATUSSHOW SLAVE STATUS(Aurora MySQL 版本 1 和 2)或 SHOW REPLICA STATUS(Aurora MySQL 版本 3)语句不返回任何输出,请检查您使用的集群是否支持二进制日志复制。

您还可以在其他 Amazon 区域中的 RDS for MySQL 数据库实例或 Aurora MySQL 数据库集群之间进行复制。跨 Amazon 区域执行复制时,请确保您的数据库集群和数据库实例可公开访问。Aurora MySQL 数据库集群必须是您的 VPC 中公有子网的一部分。

如果要在 Aurora MySQL 数据库集群和另一个区域中的 Aurora MySQL 数据库集群之间配置复制,您可以在与源数据库集群不同的Amazon区域中创建一个 Aurora MySQL 数据库集群以作为只读副本。有关更多信息,请参阅 跨Amazon区域复制 Amazon Aurora MySQL 数据库集群

使用 Aurora MySQL 2.04 及更高版本,您可以在 Aurora MySQL 与为复制使用全局事务标识符 (GTID) 的外部源或目标之间复制。请确保 Aurora MySQL 数据库集群中的 GTID 相关参数具有与外部数据库的 GTID 状态兼容的设置。若要了解如何执行此操作,请参阅 将基于 GTID 的复制用于 Aurora MySQL。在 Aurora MySQL 版本 3.01 及更高版本中,您可以选择如何将 GTID 分配给从不使用 GTID 的源复制的事务。有关控制该设置的存储过程的信息,请参阅 mysql.rds_assign_gtids_to_anonymous_transactions(Aurora MySQL 版本 3 及更高版本)

警告

在 Aurora MySQL 与 MySQL 之间复制时,请确保仅使用 InnoDB 表。如果有 MyISAM 表需要复制,可以在设置复制之前使用以下命令将其转换为 InnoDB。

alter table <schema>.<table_name> engine=innodb, algorithm=copy;

设置与 Aurora MySQL 的 MySQL 复制包括以下步骤(本主题后文会详细讨论):

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

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

3. 创建复制源的快照

4. 将快照加载到副本目标

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

6. 监控副本

设置与 MySQL 或其他 Aurora 数据库集群的复制

要使用 MySQL 设置 Aurora 复制,请执行以下步骤。

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

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

数据库引擎 说明

Aurora

在 Aurora MySQL 数据库集群上开启二进制日志记录

binlog_format 参数设置为 ROWSTATEMENTMIXED。建议设置为 MIXED,除非您具有特定的 binlog 格式需求。binlog_format 参数是默认集群参数组中的集群级参数。如果要将 binlog_format 参数从 OFF 更改为其他值,您需要重启 Aurora 数据库集群以使更改生效。

有关更多信息,请参阅“Amazon Aurora 数据库集群和数据库实例参数”和“使用参数组”。

RDS for MySQL

在 Amazon RDS 数据库实例上开启二进制日志记录

您不能直接为 Amazon RDS 数据库实例开启二进制日志记录,但可以通过执行以下操作之一来开启它:

  • 为数据库实例开启自动备份。您可以在创建数据库实例时开启自动备份,也可以通过修改现有数据库实例开启备份。有关更多信息,请参阅 Amazon RDS 用户指南 中的创建数据库实例

  • 为数据库实例创建只读副本。有关更多信息,请参阅 Amazon RDS 用户指南 中的使用只读副本

MySQL (外部)

设置加密复制

要使用 Aurora MySQL 5.6 版安全地复制数据,您可以使用加密复制。

目前,仅 Aurora MySQL 5.6 版支持具有外部 MySQL 数据库的加密复制。

注意

如果您不需要使用加密复制,可以跳过以下步骤。

以下是使用加密复制的先决条件:

  • 必须在外部 MySQL 源数据库上启用安全套接字层 (SSL)。

  • 必须为 Aurora MySQL 数据库集群准备客户端密钥和客户端证书。

在加密复制期间,Aurora MySQL 数据库集群充当 MySQL 数据库服务器的客户端。Aurora MySQL 客户端的证书和密钥必须是 .pem 格式的文件。

  1. 确保您为加密复制做好以下准备:

    • 如果您没有在外部 MySQL 源数据库上启用 SSL,并且没有准备客户端密钥和客户端证书,请在 MySQL 数据库服务器上开启 SSL 并生成所需的客户端密钥和客户端证书。

    • 如果在外部源上启用了 SSL,请提供 Aurora MySQL 数据库集群的客户端密钥和证书。如果未提供,请为 Aurora MySQL 数据库集群生成新密钥和证书。要对客户端证书进行签名,您必须拥有您用来在外部 MySQL 源数据库上配置 SSL 的证书颁发机构密钥。

    有关更多信息,请参阅 MySQL 文档中的使用 openssl 创建 SSL 证书和密钥

    您需要证书颁发机构证书、客户端密钥和客户端证书。

  2. 通过 SSL 以主用户身份连接到 Aurora MySQL 数据库集群。

    有关通过 SSL 连接到 Aurora MySQL 数据库集群的信息,请参阅将 SSL/TLS 与 Aurora MySQL 数据库集群配合使用

  3. 运行 mysql.rds_import_binlog_ssl_material 存储过程,以将 SSL 信息导入到 Aurora MySQL 数据库集群中。

    对于 ssl_material_value 参数,将 Aurora MySQL 数据库集群的 .pem 格式文件中的信息插入到正确的 JSON 负载中。

    以下示例将 SSL 信息导入到 Aurora MySQL 数据库集群中。在 .pem 格式文件中,主体代码通常比示例中显示的主体代码长。

    call mysql.rds_import_binlog_ssl_material( '{"ssl_ca":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_cert":"-----BEGIN CERTIFICATE----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END CERTIFICATE-----\n","ssl_key":"-----BEGIN RSA PRIVATE KEY----- AAAAB3NzaC1yc2EAAAADAQABAAABAQClKsfkNkuSevGj3eYhCe53pcjqP3maAhDFcvBS7O6V hz2ItxCih+PnDSUaw+WNQn/mZphTk/a/gU8jEzoOWbkM4yxyb/wB96xbiFveSFJuOp/d6RJhJOI0iBXr lsLnBItntckiJ7FbtxJMXLvvwJryDUilBMTjYtwB+QhYXUMOzce5Pjz5/i8SeJtjnV3iAoG/cQk+0FzZ qaeJAAHco+CY/5WrUBkrHmFJr6HcXkvJdWPkYQS3xqC0+FmUZofz221CBt5IMucxXPkX4rWi+z7wB3Rb BQoQzd8v7yeb7OzlPnWOyN0qFU0XA246RA8QFYiCNYwI3f05p6KLxEXAMPLE -----END RSA PRIVATE KEY-----\n"}');

    有关更多信息,请参阅 mysql_rds_import_binlog_ssl_material将 SSL/TLS 与 Aurora MySQL 数据库集群配合使用

    注意

    运行该过程后,密钥会存储在文件中。要稍后删除文件,您可以运行 mysql_rds_remove_binlog_ssl_material 存储过程。

在外部 MySQL 数据库上开启二进制日志记录

  1. 从命令 Shell 中停止 mysql 服务。

    sudo service mysqld stop
  2. 编辑 my.cnf 文件(此文件通常位于 /etc 下)。

    sudo vi /etc/my.cnf

    log_binserver_id 选项添加到 [mysqld] 节。log_bin 选项为二进制日志文件提供文件名标识符。server_id 选项为源-副本关系中的服务器提供唯一标识符。

    如果不需要加密复制,请确保先为外部 MySQL 数据库启用二进制日志并关闭 SSL。

    以下是 /etc/my.cnf 文件中未加密数据的相关条目。

    log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1

    如果需要加密复制,请确保先为外部 MySQL 数据库启用 SSL 和二进制日志。

    /etc/my.cnf 文件的条目包括 MySQL 数据库服务器的 .pem 文件位置。

    log-bin=mysql-bin server-id=2133421 innodb_flush_log_at_trx_commit=1 sync_binlog=1 # Setup SSL. ssl-ca=/home/sslcerts/ca.pem ssl-cert=/home/sslcerts/server-cert.pem ssl-key=/home/sslcerts/server-key.pem

    此外,必须将 MySQL 数据库实例的 sql_mode 选项设置为 0,否则不得将该选项包含在 my.cnf 文件中。

    当连接到外部 MySQL 数据库时,记录外部 MySQL 数据库的二进制日志位置。

    mysql> SHOW MASTER STATUS;

    您的输出应类似于以下内容:

    +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000031 | 107 | | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)

    有关更多信息,请参阅 MySQL 文档中的 Setting the replication source configuration

  3. 启动 mysql 服务。

    sudo service mysqld start

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

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

在下面查找有关如何为数据库引擎保留二进制日志的说明。

数据库引擎 说明

Aurora

在 Aurora MySQL 数据库集群上保留二进制日志

您无法访问 Aurora MySQL 数据库集群的二进制日志文件。因此,您必须为复制源上的二进制日志文件选择足够长的保留时间,从而确保在 Amazon RDS 删除二进制日志文件之前将更改应用于副本。Aurora MySQL 数据库集群上的二进制日志文件最多可以保留 90 天。

如果所设置的复制以 MySQL 数据库或 RDS for MySQL 数据库实例作为副本,并且要创建副本的数据库非常大,请为二进制日志文件选择较长的保留时间,直到数据库到副本的初始复制完成,并且副本滞后达到 0。

要设置二进制日志保留时间范围,请使用 mysql_rds_set_configuration 过程,并指定 'binlog retention hours' 配置参数以及在数据库集群上保留二进制日志文件的小时数(最多为 2160 小时,即 90 天)。以下示例将二进制日志文件的保留期设置为 6 天:

CALL mysql.rds_set_configuration('binlog retention hours', 144);

复制开始之后,可以通过对副本运行 SHOW SLAVE STATUS(Aurora MySQL 版本 1 和 2)或 SHOW REPLICA STATUS(Aurora MySQL 版本 3)命令并检查 Seconds behind master 字段来验证更改是否已经应用于副本。如果 Seconds behind master 字段为 0,则表示不存在副本滞后。不存在副本滞后时,请通过将 binlog retention hours 配置参数设置为更短的时间范围缩短保留二进制日志文件的时间。

如果未指定此设置,则 Aurora MySQL 的默认值为 24 小时(1 天)。

如果您为 'binlog retention hours' 指定的值大于 2160 小时,则 Aurora MySQL 仍使用 2160。

RDS for MySQL

在 Amazon RDS 数据库实例上保留二进制日志

您也可以通过设置二进制日志保留小时数在 Amazon RDS 数据库实例上保留二进制日志文件,就如同 Aurora MySQL 数据库集群一样(如上一节所述)。

还可以通过为数据库实例创建只读副本,在 Amazon RDS 数据库实例上保留二进制日志文件。此只读副本是临时副本,仅用于保留二进制日志文件的目的。在创建只读副本后,在只读副本上调用 mysql_rds_stop_replication 过程。复制停止时,Amazon RDS 不会删除复制源上的任何二进制日志文件。设置与永久副本间的复制之后,可以在复制源与永久副本之间的副本滞后(Seconds behind master 字段)达到 0 时删除只读副本。

MySQL (外部)

在外部 MySQL 数据库上保留二进制日志

外部 MySQL 数据库上的二进制日志文件不由 Amazon RDS 进行管理,因此,它们会一直保留,直到由您删除。

复制开始之后,可以通过对副本运行 SHOW SLAVE STATUS(Aurora MySQL 版本 1 和 2)或 SHOW REPLICA STATUS(Aurora MySQL 版本 3)命令并检查 Seconds behind master 字段来验证更改是否已经应用于副本。如果 Seconds behind master 字段为 0,则表示不存在副本滞后。不存在副本滞后时,可以删除旧的二进制日志文件。

3. 创建复制源的快照

使用复制源的快照将数据的基准副本加载到您的副本上,然后从该点开始复制。

在下面查找有关如何创建数据库引擎的复制源快照的说明。

数据库引擎 说明

Aurora

创建 Aurora MySQL 数据库集群的快照

  1. 创建 Amazon Aurora 数据库集群的数据库集群快照。有关更多信息,请参阅 创建数据库集群快照

  2. 通过从刚创建的数据库集群快照进行还原来创建新的 Aurora 数据库集群。确保为存储的数据库集群保留的数据库参数组与为原始数据库集群保留的相同。这样可确保数据库集群的副本已启用二进制日志记录。有关更多信息,请参阅 从数据库集群快照还原

  3. 在控制台中,选择 Databases (数据库),然后单击还原的 Aurora 数据库集群的主实例(写入器)以显示其详细信息。滚动到近期事件。显示的事件消息包括二进制日志文件名和位置。事件消息采用以下格式。

    Binlog position from crash recovery is binlog-file-name binlog-position

    在开始复制时,保存二进制日志文件名和位置的值。

    您也可以通过 Amazon CLI 调用 describe-events 命令以获取二进制日志文件名和位置。下面是包含输出的 describe-events 命令的示例。

    PROMPT> aws rds describe-events
    { "Events": [ { "EventCategories": [], "SourceType": "db-instance", "SourceArn": "arn:aws:rds:us-west-2:123456789012:db:sample-restored-instance", "Date": "2016-10-28T19:43:46.862Z", "Message": "Binlog position from crash recovery is mysql-bin-changelog.000003 4278", "SourceIdentifier": "sample-restored-instance" } ] }

    您也可以在 MySQL 错误日志中查找最后一个 MySQL 二进制日志文件位置以获取二进制日志文件名和位置。

  4. 如果您的副本目标是另一个Amazon账户、外部 MySQL 数据库或 RDS for MySQL 数据库实例拥有的 Aurora 数据库集群,则无法从 Amazon Aurora 数据库集群快照中加载数据。但可以通过使用 MySQL 客户端连接到数据库集群并发出 mysqldump 命令,创建 Amazon Aurora 数据库集群的转储。请务必针对您创建的 Amazon Aurora 数据库集群的副本运行 mysqldump 命令。以下是示例。

    PROMPT> mysqldump --databases <database_name> --single-transaction --order-by-primary -r backup.sql -u <local_user> -p
  5. 在完成从新创建的 Aurora 数据库集群中创建数据转储后,请删除该数据库集群,因为不再需要使用该集群。

RDS for MySQL

创建 Amazon RDS 数据库实例的快照

  1. 创建 Amazon RDS 数据库实例的只读副本。有关更多信息,请参阅 Amazon Relational Database Service 用户指南 中的创建只读副本

  2. 连接到只读副本,然后运行 mysql_rds_stop_replication 过程以停止复制。

  3. 当只读副本处于 Stopped(已停止)时,连接到只读副本并运行 SHOW SLAVE STATUS(Aurora MySQL 版本 1 和 2)或 SHOW REPLICA STATUS(Aurora MySQL 版本 3)命令。从 Relay_Master_Log_File 字段检索当前二进制日志文件名,并从 Exec_Master_Log_Pos 字段检索日志文件位置。在开始复制时保存这些值。

  4. 在只读副本保持 Stopped (已停止) 状态期间,创建只读副本的数据库快照。有关更多信息,请参阅 Amazon Relational Database Service 用户指南 中的创建数据库快照

  5. 删除只读副本。

MySQL (外部)

创建外部 MySQL 数据库的快照

  1. 创建快照之前,您需要确保快照的二进制日志位置随源实例中的数据保持最新状态。为此,必须先使用以下命令停止对实例进行的任何写入操作:

    mysql> FLUSH TABLES WITH READ LOCK;
  2. 使用 mysqldump 命令创建 MySQL 数据库的转储,如下所示:

    PROMPT> sudo mysqldump --databases <database_name> --master-data=2 --single-transaction \ --order-by-primary -r backup.sql -u <local_user> -p
  3. 创建快照之后,请使用以下命令解锁 MySQL 数据库中的表:

    mysql> UNLOCK TABLES;

4. 将快照加载到副本目标

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

在下面查找有关如何将复制源的快照加载到数据库引擎的副本目标的说明。

数据库引擎 说明

Aurora

将快照加载到 Aurora MySQL 数据库集群

  • 如果复制源的快照是数据库集群快照,则您可以从数据库集群快照进行还原,以创建新的 Aurora MySQL 数据库集群作为副本目标。有关更多信息,请参阅 从数据库集群快照还原

  • 如果复制源的快照是数据库快照,则您可以将数据从数据库快照迁移到新的 Aurora MySQL 数据库集群中。有关更多信息,请参阅 将数据迁移到 Amazon Aurora 数据库集群

  • 如果复制源的快照是 mysqldump 命令的输出,请按照以下步骤操作:

    1. mysqldump 命令的输出从复制源复制到也可以连接到 Aurora MySQL 数据库集群的位置。

    2. 使用 mysql 命令连接到 Aurora MySQL 数据库集群。以下是示例。

      PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p
    3. mysql 提示符下,运行 source 命令并向它传递您的数据库转储文件名,以便将数据加载到 Aurora MySQL 数据库集群中,例如:

      mysql> source backup.sql;

RDS for MySQL

将快照加载到 Amazon RDS 数据库实例

  1. mysqldump 命令的输出从复制源复制到也可以连接到 MySQL 数据库实例的位置。

  2. 使用 mysql 命令连接到 MySQL 数据库实例。以下是示例。

    PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p
  3. mysql 提示符下,运行 source 命令并向它传递您的数据库转储文件名,以便将数据加载到 MySQL 数据库实例中,例如:

    mysql> source backup.sql;

MySQL (外部)

将快照加载到外部 MySQL 数据库中

无法将数据库快照或数据库集群快照加载到外部 MySQL 数据库中。您必须使用 mysqldump 命令的输出。

  1. mysqldump 命令的输出从复制源复制到也可以连接到 MySQL 数据库的位置。

  2. 使用 mysql 命令连接到 MySQL 数据库。以下是示例。

    PROMPT> mysql -h <host_name> -port=3306 -u <db_master_user> -p
  3. mysql 提示符下,运行 source 命令并向它传递您的数据库转储文件名,以便将数据加载到 MySQL 数据库中。以下是示例。

    mysql> source backup.sql;

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

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

此外,创建专用于复制的用户 ID。以下是示例。

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

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

GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'<domain_name>';

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

GRANT USAGE ON *.* TO 'repl_user'@'<domain_name>' REQUIRE SSL;
注意

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

在下面查找有关如何对数据库引擎开启复制的说明。

数据库引擎 说明

Aurora

从 Aurora MySQL 数据库集群中开启复制

  1. 如果数据库集群副本目标是从数据库集群快照创建的,请连接到数据库集群副本目标并发出 SHOW MASTER STATUS 命令。从 File 字段检索当前二进制日志文件名,并从 Position 字段检索日志文件位置。

    如果数据库集群副本目标是从数据库快照创建的,则您需要作为复制起点的二进制日志文件和二进制日志位置。您在创建复制源的快照时,从 SHOW SLAVE STATUS(Aurora MySQL 版本 1 和 2)或 SHOW REPLICA STATUS(Aurora MySQL 版本 3)命令中检索这些值。

  2. 连接到数据库集群并发出 mysql_rds_set_external_master(Aurora MySQL 版本 1 和 2)、mysql_rds_set_external_source(Aurora MySQL 版本 3 及更高版本)和 mysql_rds_start_replication 程序,以使用上一步中的二进制日志文件名称和位置开始与复制源之间的复制。以下是示例。

    For Aurora MySQL version 1 and 2: CALL mysql.rds_set_external_master ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0); For Aurora MySQL version 3 and higher: CALL mysql.rds_set_external_source ('mydbinstance.123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0); For all versions: CALL mysql.rds_start_replication;

RDS for MySQL

从 Amazon RDS 数据库实例中开启复制

  1. 如果数据库实例副本目标是从数据库快照创建的,则您需要作为复制起点的二进制日志文件和二进制日志位置。您在创建复制源的快照时,从 SHOW SLAVE STATUS(Aurora MySQL 版本 1 和 2)或 SHOW REPLICA STATUS(Aurora MySQL 版本 3)命令中检索这些值。

  2. 连接到数据库实例,然后发出 mysql_rds_set_external_master mysql_rds_start_replication 过程,以使用上一步中的二进制日志文件名和位置启动与复制源之间的复制。以下是示例。

    For Aurora MySQL version 1 and 2: CALL mysql.rds_set_external_master ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0); For Aurora MySQL version 3 and higher: CALL mysql.rds_set_external_source ('mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0); For all versions: CALL mysql.rds_start_replication;

MySQL (外部)

开启从外部 MySQL 数据库进行复制

  1. 检索作为复制起点的二进制日志文件和二进制日志位置。您在创建复制源的快照时,从 SHOW SLAVE STATUS(Aurora MySQL 版本 1 和 2)或 SHOW REPLICA STATUS(Aurora MySQL 版本 3)命令中检索这些值。如果外部 MySQL 副本目标是从使用 mysqldump 选项的 --master-data=2 命令的输出填充的,则二进制日志文件和二进制日志位置包含在该输出中。以下是示例。

    -- -- Position to start replication or point-in-time recovery from -- -- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.000031', MASTER_LOG_POS=107;
  2. 连接到外部 MySQL 副本目标,然后发出 CHANGE MASTER TOSTART SLAVE(Aurora MySQL 版本 1 和 2)或 START REPLICA(Aurora MySQL 版本 3),以使用上一步中的二进制日志文件名和位置开始与复制源之间的复制,例如:

    CHANGE MASTER TO MASTER_HOST = 'mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com', MASTER_PORT = 3306, MASTER_USER = 'repl_user', MASTER_PASSWORD = '<password>', MASTER_LOG_FILE = 'mysql-bin-changelog.000031', MASTER_LOG_POS = 107; -- And one of these statements depending on your engine version: START SLAVE; -- Aurora MySQL version 1 and 2 START REPLICA; -- Aurora MySQL version 3

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

6. 监控副本

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

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

停止 Aurora 和 MySQL 之间或 Aurora 和其他 Aurora 数据库集群之间的复制

要停止对 MySQL 数据库实例、外部 MySQL 数据库或其他 Aurora 数据库集群进行的二进制日志复制,请执行以下步骤 (本主题后文有详细讨论)。

1. 在副本目标上停止二进制日志复制

2. 在复制源上关闭二进制日志记录

1. 在副本目标上停止二进制日志复制

在下面查找有关如何停止数据库引擎的二进制日志复制的说明。

数据库引擎 说明

Aurora

在 Aurora MySQL 数据库集群副本目标上停止二进制日志复制

连接到作为副本目标的 Aurora 数据库集群,然后调用 mysql_rds_stop_replication 过程。

RDS for MySQL

在 Amazon RDS 数据库实例上停止二进制日志复制

连接到作为副本目标的 RDS 数据库实例,然后调用 mysql_rds_stop_replication 过程。mysql.rds_stop_replication 过程仅适用于 MySQL 5.5 和更高版本、5.6 和更高版本和 5.7 和更高版本。

MySQL (外部)

在外部 MySQL 数据库上停止二进制日志复制

连接到 MySQL 数据库并调用 STOP REPLICATION 命令。

2. 在复制源上关闭二进制日志记录

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

数据库引擎 说明

Aurora

在 Amazon Aurora 数据库集群上关闭二进制日志记录

  1. 连接到作为复制源的 Aurora 数据库集群,然后将二进制日志保留时间范围设置为 0。要设置二进制日志保留时间范围,请使用 mysql_rds_set_configuration 过程,并指定“binlog retention hours”的配置参数以及在数据库集群上保留二进制日志文件的小时数(此处为 0),如以下示例中所示。

    CALL mysql.rds_set_configuration('binlog retention hours', 0);
  2. 在复制源上将 binlog_format 参数设置为 OFFbinlog_format 参数是默认集群参数组中的集群级参数。

    在更改 binlog_format 参数值后,重启数据库集群以便更改生效。

    有关更多信息,请参阅“Amazon Aurora 数据库集群和数据库实例参数”和“修改数据库参数组中的参数”。

RDS for MySQL

在 Amazon RDS 数据库实例上关闭二进制日志记录

您不能直接为 Amazon RDS 数据库实例关闭二进制日志记录,但可以通过执行以下操作来关闭它:

  1. 为数据库实例关闭自动备份。您可通过修改现有数据库实例并将 Backup Retention Period(备份保留期)设置为 0 来关闭自动备份。有关更多信息,请参阅 Amazon Relational Database Service 用户指南 中的修改 Amazon RDS 数据库实例使用备份

  2. 删除数据库实例的所有只读副本。有关更多信息,请参阅 Amazon Relational Database Service 用户指南 中的使用 MariaDB、MySQL 和 PostgreSQL 数据库实例的只读副本

MySQL (外部)

在外部 MySQL 数据库上关闭二进制日志记录

连接到 MySQL 数据库并调用 STOP REPLICATION 命令。

  1. 从命令 shell 中停止 mysqld 服务,

    sudo service mysqld stop
  2. 编辑 my.cnf 文件(此文件通常位于 /etc 下)。

    sudo vi /etc/my.cnf

    log_bin 部分中删除 server_id [mysqld] 选项。

    有关更多信息,请参阅 MySQL 文档中的 Setting the replication source configuration

  3. 启动 mysql 服务。

    sudo service mysqld start

使用 Amazon Aurora 为 MySQL 数据库扩展读取

您可以将 Amazon Aurora 用于 MySQL 数据库实例,以便利用 Amazon Aurora 的读取扩展功能并为 MySQL 数据库实例扩展读取工作负载。要使用 Aurora 对 MySQL 数据库实例进行读取扩展,请创建 Amazon Aurora MySQL 数据库集群并使它成为 MySQL 数据库实例的只读副本。这适用于 RDS for MySQL 数据库实例或是在 Amazon RDS 外部运行的 MySQL 数据库。

有关创建 Amazon Aurora 数据库集群的信息,请参阅创建 Amazon Aurora 数据库集群

在 MySQL 数据库实例与 Amazon Aurora 数据库集群之间设置复制时,请确保遵循以下准则:

  • 当您引用 Amazon Aurora 数据库集群时,使用 Amazon Aurora MySQL 数据库集群终端节点地址。如果发生故障转移,则提升为 Aurora 数据库集群主实例的 Aurora MySQL 副本继续使用数据库集群终端节点地址。

  • 在您的写入器实例上维护二进制日志,直至您确认其已应用于 Aurora 副本。这种维护将确保您可以在发生故障时还原写入器实例。

重要

当使用自管理复制时,您负责监控和解决可能发生的所有复制问题。有关更多信息,请参阅 诊断并解决只读副本之间的滞后

注意

对 Amazon Aurora MySQL 数据库集群启动复制功能所需的权限受到限制且对 Amazon RDS 主用户不可用。为此,您必须使用 Amazon RDS mysql_rds_set_external_master mysql_rds_start_replication 过程设置 Amazon Aurora MySQL 数据库集群和 MySQL 数据库实例之间的复制。

在 Amazon RDS 上启动外部源实例和 MySQL 数据库实例之间的复制

  1. 将源 MySQL 数据库实例设为只读:

    mysql> FLUSH TABLES WITH READ LOCK; mysql> SET GLOBAL read_only = ON;
  2. 对源 MySQL 数据库实例运行 SHOW MASTER STATUS 命令以确定二进制日志位置。将会收到类似于以下示例的输出:

    File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------
  3. 使用 mysqldump 将数据库从外部 MySQL 数据库实例复制到 Amazon Aurora MySQL 数据库集群。对于非常大的数据库,您可能希望使用 Amazon Relational Database Service 用户指南 中的将数据导入到 MySQL 或 MariaDB 数据库实例并减少停机时间中的过程。

    对于 Linux、macOS 或 Unix:

    mysqldump \ --databases <database_name> \ --single-transaction \ --compress \ --order-by-primary \ -u <local_user> \ -p <local_password> | mysql \ --host aurora_cluster_endpoint_address \ --port 3306 \ -u <RDS_user_name> \ -p <RDS_password>

    对于 Windows:

    mysqldump ^ --databases <database_name> ^ --single-transaction ^ --compress ^ --order-by-primary ^ -u <local_user> ^ -p <local_password> | mysql ^ --host aurora_cluster_endpoint_address ^ --port 3306 ^ -u <RDS_user_name> ^ -p <RDS_password>
    注意

    确保 -p 选项和输入的密码之间没有空格。

    --host 命令中使用 --user (-u)--port-pmysql 选项,以指定用于连接到 Aurora 数据库集群的主机名、用户名、端口和密码。主机名是 Amazon Aurora 数据库集群终端节点中的 DNS 名称,例如 mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com。您可以在 Amazon RDS 管理控制台上的集群详细信息中找到终端节点值。

  4. 再次将源 MySQL 数据库实例设为可写:

    mysql> SET GLOBAL read_only = OFF; mysql> UNLOCK TABLES;

    有关生成备份以用于复制的更多信息,请参阅 MySQL 文档中的Backing up a source or replica by making it read only

  5. 在 Amazon RDS 管理控制台中,将托管源 MySQL 数据库的服务器的 IP 地址添加到 Amazon Aurora 数据库集群的 VPC 安全组。有关修改 VPC 安全组的更多信息,请参阅 Amazon Virtual Private Cloud 用户指南 中的您的 VPC 的安全组

    您可能还需要配置本地网络以允许来自 Amazon Aurora 数据库集群的 IP 地址的连接,以便它能与源 MySQL 实例进行通信。要查找 Amazon Aurora 数据库集群的 IP 地址,请使用 host 命令。

    host <aurora_endpoint_address>

    主机名是 Amazon Aurora 数据库集群终端节点中的 DNS 名称。

  6. 通过使用所选的客户端,连接到外部 MySQL 实例并创建用于复制的 MySQL 用户。此账户仅用于复制,并且必须仅供您的域使用以增强安全性。以下是示例。

    CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';
  7. 对于外部 MySQL 实例,向复制用户授予 REPLICATION CLIENTREPLICATION SLAVE 权限。例如,要为您的域的“REPLICATION CLIENT”用户授予对所有数据库的 REPLICATION SLAVErepl_user 权限,请发出以下命令。

    GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'mydomain.com' IDENTIFIED BY '<password>';
  8. 在设置复制之前,请创建 Aurora MySQL 数据库集群的手动快照以作为只读副本。如果您需要将数据库集群作为只读副本来重新建立复制,则可从此快照还原 Aurora MySQL 数据库集群,而不必将 MySQL 数据库实例中的数据导入新的 Aurora MySQL 数据库集群。

  9. 使 Amazon Aurora 数据库集群成为副本。通过使用 mysql_rds_set_external_master 过程,以主用户身份连接到 Amazon Aurora 数据库集群,并将源 MySQL 数据库指定为复制主实例。使用在步骤 2 中确定的主日志文件名和主日志位置。以下是示例。

    For Aurora MySQL version 1 and 2: CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0); For Aurora MySQL version 3 and higher: CALL mysql.rds_set_external_source ('mymasterserver.mydomain.com', 3306, 'repl_user', '<password>', 'mysql-bin-changelog.000031', 107, 0);
  10. 在 Amazon Aurora 数据库集群上,发出 mysql_rds_start_replication 过程以开始复制。

    CALL mysql.rds_start_replication;

在源 MySQL 数据库实例与 Amazon Aurora 数据库集群之间建立复制之后,可以将 Aurora 副本添加到 Amazon Aurora 数据库集群。随后可以连接到 Aurora 副本以对数据进行读取扩展。有关创建 Aurora 副本的信息,请参阅将 Aurora 副本添加到数据库集群

优化二进制日志复制

接下来,您可以了解如何优化二进制日志复制性能和排查 Aurora MySQL 中的相关问题。

提示

本讨论假定您熟悉 MySQL 二进制日志复制机制及其工作原理。有关背景信息,请参阅 MySQL 文档中的复制实施

多线程二进制日志复制(Aurora MySQL 版本 3 及更高版本)

使用多线程二进制日志复制时,SQL 线程会从中继日志中读取事件并将其排队,以便 SQL 工作线程应用。SQL 工作线程由协调器线程管理。尽可能并行应用二进制日志事件。

当 Aurora MySQL 实例配置为使用二进制日志复制时,预设情况下,副本实例使用单线程复制。要启用多线程复制,请在您的自定义参数组中将 replica_parallel_workers 参数更新为大于零的值。

以下配置选项可以帮助您优化多线程复制。有关使用信息,请参阅 MySQL 参考手册中的复制和二进制日志记录选项和变量

最佳配置取决于多个因素。例如,二进制日志复制的性能受数据库工作负载特征和副本运行所在的数据库实例类的影响。因此,我们建议您在将新参数设置应用于生产实例之前,彻底测试对这些配置参数的所有更改。

  • replica_parallel_workers

  • replica_parallel_type

  • replica_preserve_commit_order

  • binlog_transaction_dependency_tracking

  • binlog_transaction_dependency_history_size

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

优化二进制日志复制(Aurora MySQL 2.10 及更高版本)

在 Aurora MySQL 2.10 及更高版本中,Aurora 会自动将称为二进制日志 I/O 缓存的优化应用于二进制日志复制。通过缓存最近提交的二进制日志事件,此优化旨在提高二进制日志转储线程性能,同时限制对二进制日志源实例上前台事务的影响。

注意

用于此功能的内存独立于 MySQL binlog_cache 设置。

此功能不适用于使用 db.t2db.t3 实例类的 Aurora 数据库实例。

您无需调整任何配置参数即可启用此优化。特别是,如果在早期 Aurora MySQL 版本中将配置参数 aurora_binlog_replication_max_yield_seconds 调整为非零值,请在 Aurora MySQL 2.10 及更高版本中将其重新设置为零。

Aurora MySQL 2.10 及更高版本中提供了状态变量 aurora_binlog_io_cache_readsaurora_binlog_io_cache_read_requests。这些状态变量可帮助您监控从二进制日志 I/O 缓存读取数据的频率。

  • aurora_binlog_io_cache_read_requests 显示来自缓存的二进制日志输入/输出读取请求的数量。

  • aurora_binlog_io_cache_reads 显示从缓存检索信息的二进制日志输入/输出读取的数量。

以下 SQL 查询计算利用缓存信息的二进制日志读取请求的百分比。在此情况下,比率越接近 100,就越好。

mysql> SELECT (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads') / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests') * 100 as binlog_io_cache_hit_ratio; +---------------------------+ | binlog_io_cache_hit_ratio | +---------------------------+ | 99.99847949080622 | +---------------------------+

二进制日志 I/O 缓存功能还包括与二进制日志转储线程相关的新指标。转储线程是当新的二进制日志副本连接到二进制日志源实例时创建的线程。

转储线程指标每 60 秒输出到数据库日志中一次,并带有前缀 [Dump thread metrics]。这些指标包括每个二进制日志副本的信息,例如,Secondary_idSecondary_uuid、二进制日志文件名以及每个副本读取的位置。这些指标还包括 Bytes_behind_primary,表示复制源和副本之间的距离(以字节为单位)。此指标衡量副本 I/O 线程的滞后。该数字不同于副本 SQL 应用程序线程的滞后,后者通过二进制日志副本上的 seconds_behind_master 指标表示。您可以通过检查距离是减少还是增加来确定二进制日志副本是跟上源还是落后。

优化二进制日志复制(Aurora MySQL 2.04.5 至 2.09)

要优化 Aurora MySQL 的二进制日志复制,您可以调整以下集群级优化参数。这些参数可帮助您在二进制日志源实例的延迟和复制滞后之间指定适当的平衡。

  • aurora_binlog_use_large_read_buffer

  • aurora_binlog_read_buffer_size

  • aurora_binlog_replication_max_yield_seconds

注意

对于兼容 MySQL 5.7 的集群,您可以在 Aurora MySQL 版本 2.04.5 至 2.09.* 中使用这些参数。在 Aurora MySQL 2.10.0 及更高版本中,这些参数被二进制日志 I/O 缓存优化所取代,无需使用这些参数。

对于兼容 MySQL 5.6 的集群,您可以在 Aurora MySQL 版本 1.17.6 及更高版本中使用这些参数。

大型读取缓冲区和最大生成率优化概述

当集群处理大量事务时,如果二进制日志转储线程访问 Aurora 集群卷,您可能会遇到二进制日志复制性能降低的情况。您可以使用参数 aurora_binlog_use_large_read_bufferaurora_binlog_replication_max_yield_secondsaurora_binlog_read_buffer_size 帮助最大限度减少这种类型的争用。

假设您有一个情况:aurora_binlog_replication_max_yield_seconds 设置为大于 0 并且转储线程的当前二进制日志文件处于活动状态。在这种情况下,二进制日志转储线程最多会等待指定的秒数,以便事务填充当前二进制日志文件。此等待期避免了单独复制每个二进制日志事件可能引起的争用。但是,这样做会增加二进制日志副本的副本滞后。这些副本可能落后于源,落后的描述与 aurora_binlog_replication_max_yield_seconds 设置相同。

当前的二进制日志文件表示转储线程当前正在读取以执行复制的二进制日志文件。我们认为一个二进制日志文件在更新或打开以供传入事务更新时,该二进制日志文件处于活动状态。Aurora MySQL 填满活动的二进制日志文件后,MySQL 会创建并切换到新的二进制日志文件。旧二进制日志文件变为非活动状态。传入的事务不再更新它。

注意

在调整这些参数之前,请衡量一段时间内的事务延迟和吞吐量。即使偶尔出现争用,您也可能会发现二进制日志复制性能稳定且延迟低。

aurora_binlog_use_large_read_buffer

如果此参数设置为 1,Aurora MySQL 会基于参数 aurora_binlog_read_buffer_sizeaurora_binlog_replication_max_yield_seconds 的设置优化二进制日志复制。如果 aurora_binlog_use_large_read_buffer 为 0,Aurora MySQL 会忽略 aurora_binlog_read_buffer_sizeaurora_binlog_replication_max_yield_seconds 参数的值。

aurora_binlog_read_buffer_size

具有较大读取缓冲区的二进制日志转储线程可通过读取每个输入/输出的更多事件来最大限度地减少读取输入/输出操作的数量。参数 aurora_binlog_read_buffer_size 设置读取缓冲区大小。大型读取缓冲区可以减少生成大量二进制日志数据的工作负载的二进制日志争用。

注意

此参数仅在集群也具有 aurora_binlog_use_large_read_buffer=1 设置时才有效。

提高读取缓冲区的大小不会影响二进制日志复制的性能。二进制日志转储线程不会等待更新事务填满读缓冲区。

aurora_binlog_replication_max_yield_seconds

如果您的工作负载需要较低的事务延迟,并且可以容忍某些复制延迟,您可以提高 aurora_binlog_replication_max_yield_seconds 参数。此参数控制集群中的二进制日志复制的最大生成属性。

注意

此参数仅在集群也具有 aurora_binlog_use_large_read_buffer=1 设置时才有效。

Aurora MySQL 可立即识别对 aurora_binlog_replication_max_yield_seconds 参数值的任何更改。您无需重新启动数据库实例。但是,开启此设置后,只有当当前二进制日志文件达到 128MB 的最大大小并轮换到新文件时,转储线程才开始生成。

相关参数

使用以下数据库集群参数开启二进制日志优化。

Aurora MySQL 版本 2.04.5 及更高版本的二进制日志优化参数
参数 默认值 有效值 描述
aurora_binlog_use_large_read_buffer 1 0, 1 切换开启复制改进功能。当它为 1 时,二进制日志转储线程将使用 aurora_binlog_read_buffer_size 进行二进制日志复制;否则使用默认缓冲区大小 (8K)。
aurora_binlog_read_buffer_size 5242880 8192-536870912 参数 aurora_binlog_use_large_read_buffer 设置为 1 时,二进制日志转储线程使用的读取缓冲区大小。
aurora_binlog_replication_max_yield_seconds 0 0-36000 对于 Aurora MySQL 版本 2.04.5–2.04.8 和 2.05–2.08.*,最大可接受值为 45。您可以在 2.04.9 及更高版本的 2.04.* 以及 2.09 及更高版本上将其调整为更高的值。仅当参数 aurora_binlog_use_large_read_buffer 设置为 1 时,此参数才有效。
Aurora MySQL 版本 1.17.6 及更高版本的二进制日志优化参数
参数 默认值 有效值 描述
aurora_binlog_use_large_read_buffer 0 0, 1 切换开启复制改进功能。当它为 1 时,二进制日志转储线程将使用 aurora_binlog_read_buffer_size 进行二进制日志复制。否则,将使用默认缓冲区大小 (8 KB)。
aurora_binlog_read_buffer_size 5242880 8192-536870912 参数 aurora_binlog_use_large_read_buffer 设置为 1 时,二进制日志转储线程使用的读取缓冲区大小。
aurora_binlog_replication_max_yield_seconds 0 0-36000 二进制日志转储线程将当前二进制日志文件(前台查询使用的文件)复制到副本时的最长生成秒数。仅当参数 aurora_binlog_use_large_read_buffer 设置为 1 时,此参数才有效。
启用二进制日志复制的最大生成率机制

您可以按如下方式开启二进制日志复制最大生成率优化。这样做可以最大限度地减少二进制日志源实例上的事务延迟。但是,您可能会遇到更高的复制滞后。

要为 Aurora MySQL 集群开启最大生成率二进制日志优化

  1. 使用以下参数设置创建或编辑数据库集群参数组:

    • aurora_binlog_use_large_read_buffer:使用值 ON 或 1 开启。

    • aurora_binlog_replication_max_yield_seconds:指定一个大于 0 的值。

  2. 将数据库集群参数组与作为二进制日志源的 Aurora MySQL 集群相关联。为此,请按照 使用参数组 中的过程进行操作。

  3. 确认参数更改生效。为此,请在二进制日志源实例上运行以下查询。

    SELECT @@aurora_binlog_use_large_read_buffer, @@aurora_binlog_replication_max_yield_seconds;

    您的输出应类似于以下内容。

    +---------------------------------------+-----------------------------------------------+ | @@aurora_binlog_use_large_read_buffer | @@aurora_binlog_replication_max_yield_seconds | +---------------------------------------+-----------------------------------------------+ | 1 | 45 | +---------------------------------------+-----------------------------------------------+
关闭二进制日志复制最大生成率优化

您可以按如下方式关闭二进制日志复制最大生成率优化。这样做可最大限度地减少复制滞后。但是,在二进制日志源实例上,您可能会遇到更高的延迟。

要关闭 Aurora MySQL 集群的最大生成率优化

  1. 确保与 Aurora MySQL 集群关联的数据库集群参数组将 aurora_binlog_replication_max_yield_seconds 设置为 0。有关使用参数组设置配置参数的更多信息,请参阅 使用参数组

  2. 确认参数更改生效。为此,请在二进制日志源实例上运行以下查询。

    SELECT @@aurora_binlog_replication_max_yield_seconds;

    您的输出应类似于以下内容。

    +-----------------------------------------------+ | @@aurora_binlog_replication_max_yield_seconds | +-----------------------------------------------+ | 0 | +-----------------------------------------------+
关闭大型读取缓冲区

您可以按如下方式关闭整个大型读取缓冲区功能。

要关闭 Aurora MySQL 集群的大型二进制日志读缓冲区

  1. aurora_binlog_use_large_read_buffer 重置为 OFF 或 0。

    确保与 Aurora MySQL 集群关联的数据库集群参数组将 aurora_binlog_use_large_read_buffer 设置为 0。有关使用参数组设置配置参数的更多信息,请参阅 使用参数组

  2. 在二进制日志源实例上,运行以下查询。

    SELECT @@ aurora_binlog_use_large_read_buffer;

    您的输出应类似于以下内容。

    +---------------------------------------+ | @@aurora_binlog_use_large_read_buffer | +---------------------------------------+ | 0 | +---------------------------------------+

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

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

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