Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

优化 Aurora MySQL 的二进制日志复制

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

多线程二进制日志复制

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

Aurora MySQL 版本 3 和 Aurora MySQL 2.12.1 及更高版本支持多线程二进制日志复制。

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

对于 Aurora MySQL 版本 3.04 及更高版本，复制默认是多线程的，replica_parallel_workers 设置为 4。您可以在自定义参数组中修改此参数。

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

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

在 Aurora MySQL 版本 3.06 及更高版本中，在为具有多个二级索引的大型表复制事务时，可以提高二进制日志副本的性能。此特征引入了一个线程池，用于在二进制日志副本上并行应用二级索引更改。该特征由 aurora_binlog_replication_sec_index_parallel_workers 数据库集群参数控制，该参数控制可用于应用二级索引更改的并行线程总数。默认情况下，此参数设置为 0（禁用）。启用此特征不需要重启实例。要启用此特征，请停止正在进行的复制，设置所需的并行工作线程数，然后重新开始复制。

您也可以将此参数用作全局变量，其中 n 是并行工作线程的数量：

SET global aurora_binlog_replication_sec_index_parallel_workers=n;

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

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

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

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

以下 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_id、Secondary_uuid、二进制日志文件名以及每个副本读取的位置。这些指标还包括 Bytes_behind_primary，表示复制源和副本之间的距离（以字节为单位）。此指标衡量副本 I/O 线程的滞后。该数字不同于副本 SQL 应用程序线程的滞后，后者通过二进制日志副本上的 seconds_behind_master 指标表示。您可以通过检查距离是减少还是增加来确定二进制日志副本是跟上源还是落后。

优化二进制日志复制（Aurora MySQL 版本 2 至 2.09）

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

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

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

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

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

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

相关参数

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

启用二进制日志复制的最大生成率机制

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

关闭二进制日志复制最大生成率优化

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

关闭大型读取缓冲区

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