本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
MySQL 端点故障排除
本节包含特定于 MySQL 的复制场景。Amazon DMS 定期扫描 MySQL 二进制日志以复制更改。以下情况下，此过程可能会增加延迟：
源上长时间运行的事务
由于 MySQL 仅将已提交的事务写入二进制日志，因此长时间运行的事务会导致与查询运行时间成比例的延迟峰值。
要识别长时间运行的事务，请使用以下查询或使用慢速查询日志：
SHOW FULL PROCESSLIST;
有关使用慢速查询日志的信息，请参阅 MySQL 文档
为避免长时间运行的事务导致延迟峰值，请重构源事务，以缩短查询运行时间或增加提交频率。
源端工作负载过高
由于 DMS CDC 是单线程的，因此大量事务会增加源延迟。要确定源延迟是否由于工作负载繁重而造成，请将出现延迟期间生成的二进制日志的数量和大小，与出现延迟之前生成的日志的数量和大小进行比较。要检查二进制日志和 DMS CDC 线程状态，请使用以下查询：
SHOW BINARY LOGS; SHOW PROCESSLIST;
有关 CDC 二进制日志转储线程状态的更多信息，请参阅复制源线程状态
您可以将源上生成的最新二进制日志位置与 DMS 当前正在处理的事件进行比较来确定延迟。要确定源上最新的二进制日志，请执行以下操作：
在 SOURCE_CAPTURE 组件上启用调试日志。
从任务调试日志中，检索 DMS 处理二进制日志和位置详细信息。
使用以下查询来确定源上最新的二进制日志：
SHOW MASTER STATUS;
要进一步优化性能，请调整 EventsPollInterval. 默认情况下，DMS 每 5 秒轮询一次二进制日志，但您可以通过降低此频率来提高性能。有关 EventsPollInterval 设置的更多信息，请参阅使用 MySQL 作为来源时的端点设置 Amazon DMS。
二进制日志争用
迁移包含大量数据的多个表时，对于 MySQL 5.7.2 或更高版本，建议将表拆分为单独的任务。在 MySQL 5.7.2 及更高版本中，主转储线程创建的锁争用较少并提高了吞吐量。因此，转储线程在读取事件时不再锁定二进制日志。这意味着多个转储线程可以同时读取二进制日志文件。这还意味着转储线程可以在客户端写入二进制日志时读取二进制日志。有关转储线程的更多信息，请参阅复制线程
对于 5.7.2 之前版本的 MySQL 源，要提高复制性能，请尝试使用 CDC 组件整合任务。