dts增量迁移卡在“订阅失败”或“延迟飙升”的直接原因是mysql源端binlog_format非row、binlog_row_image非full、权限不足（缺replication slave/client）、未显式勾选订阅表，或dts误连从库而非主库。
为什么DTS增量迁移常卡在“订阅失败”或“延迟飙升”
直接结论：不是网络通了就能跑通，核心堵点在MySQL源端的binlog格式、权限、GTID三者是否对齐阿里云DTS的硬性要求。本地IDC的MySQL往往默认是MIXED或STATEMENT，而DTS增量订阅强制要求ROW；同时binlog_row_image必须为FULL，否则DTS解析不到完整字段变更。
- 检查当前配置：
SHOW VARIABLES LIKE 'binlog_format';和SHOW VARIABLES LIKE 'binlog_row_image'; - 若不满足，需在
my.cnf中追加并重启：binlog_format = ROW、binlog_row_image = FULL - 确认MySQL用户已授予
REPLICATION SLAVE和REPLICATION CLIENT权限，仅SELECT不够 - DTS控制台创建数据订阅时，“订阅对象”里必须显式勾选表——即使选了库，DTS也不会自动订阅其下所有表
如何让DTS稳定拉取binlog而不被本地MySQL主从切换打断
本地IDC若启用了主从架构，且DTS直连的是从库（常见误操作），一旦发生主从切换，DTS会因Could not find first log file name in binary log index file报错中断。DTS必须连接主库，且该主库需开启log_slave_updates=ON（确保从库也写binlog，但DTS本身不依赖这点，关键是避免连错节点）。
- DTS数据订阅任务的“源库连接信息”务必填主库IP+端口，不可填VIP或中间件地址（如ProxySQL、DBProxy），DTS不支持透明转发
- 若IDC使用MHA或Orchestrator等高可用方案，需确保DTS连接串指向的是当前Master，建议用固定DNS名并配合健康检查更新A记录，而非依赖VIP漂移
- 主库
max_binlog_size不宜设过大（如1G），否则单个binlog文件过大，DTS拉取超时概率上升；建议保持默认100MB左右
DTS订阅通道里的“消费位点”怎么手动重置才安全
当本地MySQL执行了RESET MASTER、PURGE BINARY LOGS，或DTS任务暂停过久导致binlog被清理，DTS会报The specified binlog file does not exist。此时不能直接点“恢复任务”，必须先重置消费位点到一个存在的binlog位置，否则任务永远起不来。
- 登录本地MySQL，执行
SHOW BINARY LOGS;拿到最新可用的binlog文件名（如mysql-bin.000123） - 执行
SHOW BINLOG EVENTS IN 'mysql-bin.000123' LIMIT 1;获取该文件第一个事件的Pos（通常是4） - 在DTS控制台该订阅任务的“管理”页，点击“修改消费位点”，填入上述文件名和Pos值
- 注意：重置后DTS会从该位置重新拉取，此前未消费的变更将丢失，仅适用于测试环境或已确认无业务影响的场景
阿里云侧消费程序收到的数据为什么字段为空或时间戳异常
DTS订阅返回的JSON消息中data或old字段为空，常见于源表含TEXT/BLOB类型列但未在DTS任务中开启“订阅全字段”。另外，MySQL的TIMESTAMP列若定义为DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，DTS可能将其解析为null或固定时间，本质是DTS对隐式默认值的处理逻辑与MySQL存在差异。
- 创建DTS数据订阅时，在“高级配置”中务必勾选
订阅全字段（包括未变更字段），否则UPDATE只传变更字段，其余为null - 源表若有
JSON类型列，确认MySQL版本≥5.7.8，且DTS任务中“结构初始化”已启用（否则JSON字段会被转成字符串） - 消费端解析
eventTime字段（DTS注入的时间戳）比解析MySQL原生时间列更可靠，它代表DTS读取到该事件的系统时间，不受MySQL时区或字段默认值干扰
真正麻烦的不是配置步骤，而是本地MySQL的binlog生命周期管理和DTS消费速度的长期匹配——binlog保留时长必须严格大于DTS最大可能延迟时间，否则一断线就不可逆丢数据。
