必须从mysqldump备份文件中提取binlog起始位置：用head -n 50 backup.sql | grep "change master to"定位master_log_file和master_log_pos，二者为增量同步唯一基准，须与binlog2sql或canal的--start-file/--start-pos严格一致，否则必然丢数据或重复写入。
增量数据同步不是“选个工具就行”，而是必须和全量备份的起始点严格对齐，否则必然丢数据或重复写入。
如何从 mysqldump 备份里提取 binlog 位置
全量备份文件开头几行会记录当前 binlog 文件名和 position，这是后续增量同步的唯一起始点。别手动翻找，用 head -n 50 配合 grep 快速定位：
head -n 50 backup_20260810.sql | grep "CHANGE MASTER TO"- 输出类似：
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000042', MASTER_LOG_POS=123456789; - 提取出
MASTER_LOG_FILE和MASTER_LOG_POS两个值，它们就是binlog2sql或canal的起始参数 - 注意：如果备份时加了
--single-transaction，position 是事务一致性快照点；若没加，该位置可能已滞后于实际变更时间
binlog2sql 同步命令的关键参数控制
binlog2sql 不是拿来即用的黑盒，几个参数直接影响结果是否可用：
-
--start-file和--start-pos必须与上一步提取的值完全一致，错一位都会漏数据 -
--stop-file和--stop-pos建议暂不设置，先跑一次确认解析逻辑正确；生产环境应设为当前源库SHOW MASTER STATUS返回的最新 position -
--no-primary-key切勿启用——它会删掉主键导致目标库写入失败或主键冲突 -
--flashback仅用于生成回滚 SQL，不要在同步流程中使用，否则会把 INSERT 变成 DELETE - 输出 SQL 时务必加上
--output-dir写入文件，而不是直接管道给mysql执行，便于人工校验和重放
canal 实例启动前必须验证的三项配置
canal 模拟 slave 连接 MySQL，任何一项不匹配就会卡在连接阶段，日志只报“connect timeout”这类模糊错误：
- 源库
my.cnf中必须有：log-bin=mysql-bin、binlog-format=ROW、server-id=1（且全局唯一） - canal server 的
instance.properties中：canal.instance.master.address要写真实 IP+端口，不能用localhost或127.0.0.1（docker 网络下尤其容易错） - MySQL 授权账号需有
SELECT、REPLICATION SLAVE、REPLICATION CLIENT权限，执行：GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%';
增量同步过程中的断点续传怎么落地
没人能保证同步永远不中断，真正关键的是“断在哪、从哪续”。靠人工记 position 不现实：
-
binlog2sql方案：每次成功应用后，把最后一条 SQL 对应的end_log_pos记录到本地文件（如last_position.txt），下次启动时读取它作为--start-pos -
canal方案：依赖metaManager存储消费位点，默认用 ZooKeeper 或本地文件；若用文件模式，确保canal.instance.store.file.buffer.size足够大，否则位点刷盘延迟会导致重复消费 - 无论哪种方式，都应在同步脚本里加入校验步骤：比如对比源库
SELECT COUNT(*) FROM t WHERE update_time > '2026-08-10 00:00:00'和目标库同条件结果，差值超过阈值就告警
最常被跳过的环节是“全量备份与增量起点的时间差”——哪怕只有 2 秒，中间产生的 DML 若没被覆盖，就会永久丢失。这个 gap 必须用 FLUSH TABLES WITH READ LOCK 或 --master-data=2 配合锁表控制，不能只靠备份脚本里的 SLEEP 1。
