优化 Aurora MySQL 的二进制日志复制 - Amazon Aurora
多线程二进制日志复制优化二进制日志复制（Aurora MySQL 2.10 及更高版本）优化二进制日志复制（Aurora MySQL 版本 2 至 2.09）

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

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

提示

本讨论假定您熟悉 MySQL 二进制日志复制机制及其工作原理。有关背景信息，请参阅 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 参考手册中的复制和二进制日志记录选项和变量。

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

  • binlog_group_commit_sync_delay

  • binlog_group_commit_sync_no_delay_count

  • binlog_transaction_dependency_history_size

  • binlog_transaction_dependency_tracking

  • replica_preserve_commit_order

  • replica_parallel_type

  • replica_parallel_workers

在 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 缓存的优化应用于二进制日志复制。通过缓存最近提交的二进制日志事件，此优化旨在提高二进制日志转储线程性能，同时限制对二进制日志源实例上前台事务的影响。

注意

用于此特征的内存独立于 MySQL binlog_cache 设置。

此特征不适用于使用 db.t2 和 db.t3 实例类的 Aurora 数据库实例。

您无需调整任何配置参数即可启用此优化。特别是，如果在早期 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 缓存读取数据的频率。

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

优化二进制日志复制（Aurora MySQL 版本 2 至 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 至 2.09.* 中使用这些参数。在 Aurora MySQL 2.10.0 及更高版本中，这些参数被二进制日志 I/O 缓存优化所取代，无需使用这些参数。

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

当集群处理大量事务时，如果二进制日志转储线程访问 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_binlog_use_large_read_buffer

如果此参数设置为 1，Aurora MySQL 会基于参数 aurora_binlog_read_buffer_size 和 aurora_binlog_replication_max_yield_seconds 的设置优化二进制日志复制。如果 aurora_binlog_use_large_read_buffer 为 0，Aurora MySQL 会忽略 aurora_binlog_read_buffer_size 和 aurora_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_binlog_use_large_read_buffer 1 0, 1 切换开启复制改进特征。当其值为 1 时，二进制日志转储线程将使用 aurora_binlog_read_buffer_size 进行二进制日志复制；否则使用默认缓冲区大小（8K）。在 Aurora MySQL 版本 3 中不使用。
aurora_binlog_read_buffer_size 5242880 8192-536870912 参数 aurora_binlog_use_large_read_buffer 设置为 1 时，二进制日志转储线程使用的读取缓冲区大小。在 Aurora MySQL 版本 3 中不使用。
aurora_binlog_replication_max_yield_seconds 0 0-36000

对于版本 Aurora MySQL 2.07.*，可接受的最大值为 45。您可以在 2.09 及更高版本中将其调整为更高的值。

对于版本 2，仅当参数 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 集群相关联。为此，请按照 Amazon Aurora 的参数组 中的过程进行操作。

  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。有关使用参数组设置配置参数的更多信息，请参阅 Amazon Aurora 的参数组。

  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。有关使用参数组设置配置参数的更多信息，请参阅 Amazon Aurora 的参数组。

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

    SELECT @@ aurora_binlog_use_large_read_buffer;

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

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