必须使用binlog_format=row，因statement或mixed格式无法准确还原行级变更，涉及函数、临时表等易导致丢数据或错同步；需修改my.cnf并重启mysql。
增量同步必须依赖 binlog_format=ROW
MySQL 到腾讯云 MySQL 的增量同步，底层完全依赖源库的 binlog 日志。如果 binlog_format 是 STATEMENT 或 MIXED，DTS 或 Canal 类工具无法准确还原行级变更，尤其在涉及函数、临时表、非确定性 SQL 时会丢数据或错同步。
务必提前执行：SHOW GLOBAL VARIABLES LIKE 'binlog_format';
若不是 ROW，需修改源库配置（my.cnf 中设 binlog_format = ROW），并重启 MySQL —— 这步不可跳过，否则后续所有增量都不可靠。
DTS 增量同步阶段只读一个 binlog 连接
全量迁移完成后，DTS 进入增量同步阶段，此时它只维持一个长连接去 SHOW BINLOG EVENTS 并持续 COM_BINLOG_DUMP，对源库 CPU 和查询压力几乎为零。但前提是：
• server_id 必须唯一且 >1（避免和真实从库冲突）
• log_bin 必须为 ON
• 若源库本身是 slave，还需确认 log_slave_updates=1
这些参数不满足，DTS 会在增量阶段报错 Failed to dump binlog 或直接卡住不动。
双写兜底时要注意异步写新库的失败重试逻辑
当 DTS 全量完成、增量追平后，业务需切到“双写”模式：先写旧库，再异步写新库。这里容易出问题的是：
• 异步写失败后仅记录日志却不重试，导致新库漏数据
• 重试无幂等控制，同一条更新被重复写入多次
• 新库写入超时未设 fallback（比如降级为告警+人工补录）
建议用带重试队列（如 Kafka + 消费者 ACK）承接写新库动作，并在新库侧用 INSERT ... ON DUPLICATE KEY UPDATE 或 REPLACE INTO 保证幂等。
校验阶段源库会写入 __tencentdb__ 系统库
数据一致性校验不是只读操作。DTS 会用迁移账号在源库创建并写入 __tencentdb__ 库，里面存对比用的 checksum 和采样点。这个库虽小（通常 • 不能手动删，否则后续校验失败且无法恢复
• 若源库开启了 read_only=ON（比如高可用主备切换后），DTS 校验会直接报权限错误 —— 此时需临时关闭 read_only 或换有写权限的账号
校验本身单线程、低频，但依赖这个库存在，忽略它会导致“看起来同步完了，其实没敢信”。
