Aurora MySQL 的二进制日志复制滞后故障排除

本节针对将 Aurora MySQL 配置用于二进制日志副本的情况，提供有关二进制日志复制滞后的指导。本节涵盖了复制架构、并行复制、依赖项跟踪、监控和配置最佳实践。

二进制日志复制可在兼容 MySQL 的数据库之间复制数据。本节介绍的二进制日志复制为异步复制：源在提交事务之前，不会等待副本确认已应用更改。本节的内容不适用于半同步复制。在半同步复制中，源在提交前，会等待至少一个副本确认收到事务。例如，Amazon RDS for MySQL 的多可用区数据库集群使用半同步复制，其内容不在本节讨论范围之内。副本通过 I/O 线程与源保持持久连接，以持续流式传输二进制日志事件。本节适用于所有以 Aurora MySQL 为副本的二进制日志复制拓扑。源可以是另一个 Aurora MySQL 集群、Amazon RDS for MySQL、本地 MySQL 或 Amazon EC2 上的 MySQL。本节同样适用于将 Aurora MySQL 作为源复制到任何 MySQL 兼容目标的情况。

遇到了滞后高峰？ 跳过背景资料，从 确定复制滞后瓶颈 开始，确定瓶颈是 I/O 线程还是 SQL 线程，然后点击对应场景的链接：I/O 线程滞后故障排除 或 SQL 线程滞后故障排除。

MySQL 复制架构

MySQL 复制通过专用线程实施：

复制流程如下：

确定复制滞后瓶颈

复制滞后可能发生在两个方面：I/O 线程或 SQL 线程。第一步是确定哪个组件存在滞后。

Source_Log_File:       mysql-bin.000045
Read_Source_Log_Pos:   524288000
Relay_Source_Log_File: mysql-bin.000045
Exec_Source_Log_Pos:   524200000

File:     mysql-bin.000045
Position: 1073741824

I/O 线程滞后故障排除

I/O 线程负责从源提取二进制日志事件并将其写入中继日志。常见原因及解决方案：

针对 I/O 线程滞后的优化策略

SQL 线程滞后故障排除

当 I/O 线程已追上源，但 Seconds_Behind_Source 仍在增长时，SQL 线程是瓶颈所在。要量化滞后情况，请对 15 分钟的时间窗口进行监控。将源上的二进制日志生成速率（Position 相对于 SHOW MASTER STATUS 的增量），与副本上的 SQL 线程应用速率（Exec_Source_Log_Pos 增量）进行比较。

常见原因及解决方案：

SELECT t.table_schema, t.table_name
FROM information_schema.tables t
  LEFT JOIN information_schema.table_constraints tc
    ON t.table_schema = tc.table_schema
    AND t.table_name = tc.table_name
    AND tc.constraint_type = 'PRIMARY KEY'
WHERE tc.constraint_type IS NULL
  AND t.table_type = 'BASE TABLE'
  AND t.table_schema NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys')
ORDER BY 1;

SELECT trx_id, trx_started, trx_rows_modified, trx_query
FROM information_schema.innodb_trx
WHERE trx_rows_modified > 10000
ORDER BY trx_started;

SELECT database_name, table_name,
    MIN(last_update) AS oldest_stat_update,
    DATEDIFF(NOW(), MIN(last_update)) AS stats_age_in_days
FROM mysql.innodb_index_stats
WHERE database_name NOT IN ('mysql', 'sys')
GROUP BY database_name, table_name
HAVING stats_age_in_days > 7
ORDER BY stats_age_in_days DESC;

使用副本端复制筛选条件减少应用工作负载

Aurora MySQL 版本 3.01.0 及更高版本支持副本端的复制筛选条件。在应用过程中，使用这些筛选条件可跳过不相关的数据库或表，从而减少 SQL 线程的工作负载。副本端的筛选条件由 SQL 线程应用，I/O 线程仍会从源提取所有二进制日志事件，因此这些筛选条件仅减少应用工作，而不减少网络传输。与源端的筛选条件（仅在数据库级别运行）不同，副本端的筛选条件支持使用 replicate-do-table 和 replicate-ignore-table 实现表级粒度。有关更多信息，请参阅 使用 Aurora MySQL 配置复制筛选条件。

多线程复制（MTR）

对于 MTR，副本并行应用独立事务。它无法将单个大型事务拆分为并行的多个部分。并行度受由源写入的依赖项信息限制。

启用 MTR (replica_parallel_workers >= 2) 后，SQL 应用器将拆分为一个协调器线程和多个工作线程。协调器从中继日志中读取事务。它检查源嵌入每个事务中的逻辑时间戳（last_committed 和 sequence_number）。然后，它将独立事务分配给可用的工作线程来并行执行。如果两个事务不共享数据依赖项（即修改的是不同的行），则这两个事务是独立的。源在提交时，使用所配置的依赖项跟踪方法确定这些依赖项，并将其记录在二进制日志中。副本无法将并行度提升至源所允许的范围之外。

MTR 是推荐的默认设置

我们建议在启用 MTR 的情况下运行副本。在 MySQL 8.0.27 及更高版本中，包括基于这些版本的 Aurora MySQL 3 版本，默认启用 MTR (replica_parallel_workers=4)。在早期版本（Aurora MySQL 2.12.1 及更高版本，或基于 MySQL 8.0.27 之前版本的版本）上，请将 replica_parallel_workers 设置为 2 或更高的值来明确启用它。在并行处理不可用时，保持 MTR 启用的开销极小；只要工作负载允许，尽量让副本利用此功能。

在以下情况下，MTR 不会减少滞后：

源上的依赖项跟踪

源使用 binlog_transaction_dependency_tracking 参数，确定哪些事务可以并行应用。建议值：WRITESET。

并行类型 (replica_parallel_type)

replica_parallel_type 参数决定事务如何在工作线程之间的分配。有两种方式：

MTR 配置

更改并行工作线程设置后，重启复制：

CALL mysql.rds_stop_replication;
CALL mysql.rds_start_replication;

Aurora 特有的复制优化

Aurora MySQL 提供了以下功能来提高二进制日志复制性能。下表总结了每项功能的可用性、默认状态以及启用方法。

监控并行复制

使用以下方法，监控复制性能并确定并行应用中的瓶颈：

性能模式

要监控 MTR 的关键表：

要评估是否在工作线程之间均匀地分配了工作，请使用以下查询：

SELECT
  a.channel_name,
  rw1.thread_id AS replica_worker_thread_id,
  ts1.count_star AS number_of_trx_executed,
  ROUND((ts1.count_star / sum_count_star) * 100, 2) AS percent_of_trx_executed_by_worker
FROM (
  SELECT rw.channel_name, SUM(ts.count_star) AS sum_count_star
  FROM performance_schema.events_transactions_summary_by_thread_by_event_name AS ts
    JOIN performance_schema.replication_applier_status_by_worker AS rw
      ON ts.thread_id = rw.thread_id
  GROUP BY rw.channel_name
) AS a
JOIN performance_schema.replication_applier_status_by_worker AS rw1
  ON a.channel_name = rw1.channel_name
JOIN performance_schema.events_transactions_summary_by_thread_by_event_name AS ts1
  ON rw1.thread_id = ts1.thread_id;

如果一两个工作线程处理了大部分事务，则表明事务依赖性较高，限制了并行度。考虑在源上切换到 WRITESET 依赖项跟踪。

如果 I/O 线程和 SQL 线程的位置彼此接近，但 Seconds_Behind_Source 仍在增长，则协调器线程本身可能是瓶颈。检查 performance_schema.replication_applier_status_by_coordinator 确定是否存在缓冲延迟。协调器瓶颈通常表明严重的事务依赖，或单个协调器线程过载，无法以足够快的速度分发事件。

错误日志多线程副本统计数据

使用 log_error_verbosity=3（默认值）时，Aurora MySQL 会定期将多线程副本统计数据写入 MySQL 错误日志。您可以通过以下方式查看这些条目：

要在错误日志中定位多线程副本统计数据条目，请搜索以下示例中显示的字符串。MySQL 错误日志在此内部字符串中使用旧的术语；本文档自始至终使用首选术语“副本”。

以下是一个错误日志条目示例：

2026-05-10 14:54:28.045308 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 7215200; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 1203644200 waited (count) when Workers occupied = 1022462 waited when Workers occupied = 62349203500

要分析的关键字段：

有效示例：诊断并行应用瓶颈

以下示例演示如何使用前述对源的监控来诊断常见的并行应用瓶颈。每个示例均从相同的症状出发：Seconds_Behind_Source 持续稳步增长，且您已确认 SQL 线程是瓶颈（请参阅 确定复制滞后瓶颈）；然后使用多线程副本统计数据和性能架构来确定纠正措施。

示例 1：工作线程预调配不足

在 CloudWatch 中，ReplicaLag 指标在 30 分钟内从接近零稳步攀升至约 400 秒。副本上的 CPU 利用率保持在 55% 左右，因此副本没有受到 CPU 限制。

要确认发生滞后的位置，请间隔 60 秒运行 SHOW REPLICA STATUS 两次。Read_Source_Log_Pos 推进了约 1.2 GB，而 Exec_Source_Log_Pos 仅推进了约 300 MB。I/O 线程能够跟上源的进度，但 SQL 线程落后，因此 SQL 线程是瓶颈所在。

使用 replica_parallel_workers=4 启用了 MTR。从错误日志中检索最新的多线程副本统计数据（请参阅 错误日志多线程副本统计数据）：

2026-05-10 14:54:28.045308 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 123; events assigned = 9876544; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 8455000 waited (count) when Workers occupied = 2456789 waited when Workers occupied = 110293847000

解释关键字段：

诊断：协调器上已经就绪、可以应用的独立事务的数量，始终超过了可以运行这些事务的工作线程的数量。由于时钟冲突等待可以忽略不计，因此并行度受工作线程数量限制，而非依赖项限制。

操作：将 replica_parallel_workers 增加至副本的 vCPU 数量（例如，在 db.r6g.4xlarge 上为 16），然后重启复制：

CALL mysql.rds_stop_replication;
CALL mysql.rds_start_replication;

验证：稍后的统计数据行显示等待几乎消失，且 ReplicaLag 恢复到 5 秒以内：

2026-05-10 15:02:14.882201 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 31840552; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 9120000 waited (count) when Workers occupied = 41233 waited when Workers occupied = 5980411000

“工作线程占用时的等待”从大约 110 秒降至大约 6 秒，吞吐量（分配的事件数）增加了两倍以上。在 CPU 利用率接近 80% 时，或等待时间不再减少时，停止增加工作线程的数量。

示例 2：COMMIT_ORDER 依赖项跟踪对低并发工作负载进行串行化

源是一个运行 OLTP 工作负载的 Amazon RDS for MySQL 实例，仅有 4-8 个并发提交的应用程序线程。副本为 db.r6g.4xlarge 实例，replica_parallel_workers=16 且 replica_parallel_type=LOGICAL_CLOCK。尽管有 16 个工作线程，ReplicaLag 仍稳定在 600 秒左右，副本 CPU 利用率仅约 20%，工作线程似乎处于空闲状态。

首先，使用 性能模式 中工作线程分布查询，检查事务在各工作线程间的分配是否均匀。

+--------------+--------------------------+------------------------+-----------------------------------+
| channel_name | replica_worker_thread_id | number_of_trx_executed | percent_of_trx_executed_by_worker |
+--------------+--------------------------+------------------------+-----------------------------------+
|              |                       45 |                1903556 |                             96.41 |
|              |                       46 |                  23104 |                              1.17 |
|              |                       47 |                  18995 |                              0.96 |
|              |                       48 |                  16720 |                              0.85 |
.
.
+--------------+--------------------------+------------------------+-----------------------------------+

上述输出显示了 16 个工作线程中的前 4 个。其中一个工作线程上应用了超过 96% 的事务，而其余 15 个工作线程处于几乎空闲的状态（其余每个工作线程的执行占比均低于 0.05%）。应用过程实际上是串行执行的。

接下来，查看错误日志中的多线程副本统计数据，确认这一情况：

2026-05-10 15:22:11.110432 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 2014500; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 98712340000 waited (count) when Workers occupied = 50122 waited when Workers occupied = 1209847000

这表明问题在于依赖项，而非容量不足。检查源上的依赖项跟踪方法：

SELECT @@global.binlog_transaction_dependency_tracking;

+-------------------------------------------------+
| @@global.binlog_transaction_dependency_tracking |
+-------------------------------------------------+
| COMMIT_ORDER                                    |
+-------------------------------------------------+

根本原因：使用 COMMIT_ORDER 时，源根据在相同二进制日志组提交中一起提交的事务，来决定哪些事务可以并行运行。在这种低并发的工作负载中，每次只有少数几个线程同时提交，因此分组提交的规模非常小。因此，对于几乎每个事务，源都使用等于前一个事务的 sequence_number 的 last_committed 值进行标记，从而将其标记为依赖于前一个事务。然后，副本必须挨个应用它们，即使它们修改的是完全不相关的行，这就是为什么 16 个工作线程中有 15 个处于空闲状态。

操作：将源切换为行级依赖项跟踪，这与提交时间无关。将其设置为动态并持久化到集群（或数据库）参数组中：

SET GLOBAL binlog_transaction_dependency_tracking = WRITESET;

WRITESET 计算每个事务修改过的行的哈希值，因此涉及不同行的事务将获得独立的时间戳并且可并行应用，而无论其何时提交。确保所有表都具有主键，因为 WRITESET 会为没有主键的表生成空的写入集（请参阅 SQL 线程滞后故障排除）。在 MySQL 8.4 中，WRITESET 是默认值，此参数已不存在。

验证：更改后，工作线程分布查询显示工作均匀分配给所有工作线程（以下显示 16 个工作线程中的前 4 个；每个工作线程现在处理约 6% 的事务）：

+--------------+--------------------------+------------------------+-----------------------------------+
| channel_name | replica_worker_thread_id | number_of_trx_executed | percent_of_trx_executed_by_worker |
+--------------+--------------------------+------------------------+-----------------------------------+
|              |                       45 |                 132540 |                              6.30 |
|              |                       46 |                 125610 |                              5.97 |
|              |                       47 |                 129774 |                              6.17 |
|              |                       48 |                 122901 |                              5.84 |
.
.
+--------------+--------------------------+------------------------+-----------------------------------+

并且错误日志统计数据显示时钟冲突数量骤降，同时 ReplicaLag 降至接近零：

2026-05-10 15:41:55.204713 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 120; events assigned = 19874100; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 412300000 waited (count) when Workers occupied = 88122 waited when Workers occupied = 7019847000

“时钟冲突时的等待时间”从约 99 秒减少到约 0.4 秒，吞吐量提升了约 10 倍，瓶颈也从依赖项变为工作线程容量，此时可参照示例 1 调整工作线程数量。

示例 3：缺少主键，强制对副本进行全表扫描

ReplicaLag 在夜间批处理作业期间出现峰值，随后恢复正常，该作业运行大型 UPDATE 和 DELETE 语句。峰值期间，副本 CPU 处于中等水平，但有一个工作线程出现卡住的情况。

在副本上，运行 SHOW PROCESSLIST 并检查复制工作线程。某个工作线程在同一条语句上持续处于 Updating 状态，每次长达数秒：

+----+-------------+------+---------+----------+------+
| Id | User        | db   | Command | State    | Time |
+----+-------------+------+---------+----------+------+
| 12 | system user | app  | Connect | Updating |   38 |
+----+-------------+------+---------+----------+------+

使用 SQL 线程滞后故障排除 中的检测查询，检查哪些复制表缺少主键：

+--------------+----------------+
| table_schema | table_name     |
+--------------+----------------+
| app          | events_archive |
+--------------+----------------+

根本原因：使用基于行的二进制日志记录时，UPDATE 或 DELETE 事件中的每一行都必须先在副本上定位，然后才能应用。如果表没有主键或 NOT NULL 的唯一键，则副本会对每个受影响的行执行全表扫描。在数百万行的表上，批处理操作会转换为数百万次全表扫描，应用该操作的工作线程将陷入停滞，既阻碍了应用进度，又加剧了延迟。

操作：向表添加主键。如果您无法立即定义明确的主键，请将 sql_generate_invisible_primary_key 参数设置为 ON（适用于基于 MySQL 8.0.30 及更高版本的 Aurora MySQL 3 版本），以启用生成的不可见主键（GIPK），从而使新表自动获得主键（请参阅 SQL 线程滞后故障排除）。

验证：添加主键后，工作线程不再滞留于 Updating 状态，SQL 线程应用速率恢复正常，ReplicaLag 在下一个批处理窗口期间恢复至基线水平。

示例 4：无法并行处理单个大型事务

ReplicaLag 每天在可预测的时间急剧跳升，持续数分钟后回落至接近零。WRITESET 依赖项跟踪已启用、replica_parallel_workers=16 且所有表都有主键，因此前面的示例不适用此情况。

在峰值期间，工作线程分布查询显示一个工作线程处于忙碌状态，其余均处于空闲状态，但与示例 2 不同，错误日志中既未显示高时钟冲突，也未显示工作线程占用等待：

2026-05-10 02:13:40.551922 [Note] [MY-010559] [Repl] Multi-threaded slave statistics for channel '': seconds elapsed = 95; events assigned = 4120000; worker queues filled over overrun level = 0; waited due a Worker queue full = 0; waited due the total size = 0; waited at clock conflicts = 1530000 waited (count) when Workers occupied = 980 waited when Workers occupied = 210440000

依赖项等待和工作线程占用等待均处于较低水平，但只有一个工作线程处于活动状态。这排除了依赖项瓶颈（示例 2）和工作线程容量瓶颈（示例 1）。

检查 performance_schema.replication_applier_status_by_worker 中忙碌的工作线程，或运行 SHOW PROCESSLIST。在整个峰值期间，有一个工作线程在应用一个事务。在源上，应用作业将一条大型语句（例如，影响数百万行的 DELETE FROM orders WHERE created_at < '2025-01-01'）作为单个事务运行。

根本原因：MTR 跨多个独立事务并行处理；它无法将单个事务拆分给多个工作线程。大型事务只能由一个工作线程应用，因此增加工作线程、切换到 WRITESET 或添加主键都无济于事。有关更多信息，请参阅 多线程复制（MTR）。

操作：在源上将较大的操作拆分为较小的批次（例如，每个事务分批删除几千行，批次之间短暂暂停）。较小的事务独立提交，这样副本可以将其分散到多个工作线程中。尽可能在低流量时段安排批量作业。

验证：对作业进行分批处理后，每日 ReplicaLag 峰值趋于平缓，工作线程分布查询显示批次分散到多个工作线程，而非仅由一个工作线程处理。

监控最佳实践

尽可能降低复制滞后的最佳实践

以下建议总结了用以尽可能降低复制滞后的关键措施。有关每个主题的详细指导，请参阅交叉引用链接。