mysql如何解决迁移过程中网络抖动导致的失败_使用断点续传工具

MySQL迁移断点续传最稳方案是mydumper+myloader：mydumper按表切分并记录快照位点，myloader通过--resume跳过已成功导入的非空表，但需人工或自动化校验数据一致性。

MySQL 迁移中断后，mysqldump 本身不支持断点续传

直接使用 mysqldump 配合 mysql 进行管道或分步导入，一旦遇到网络抖动导致连接重置，整个过程就会直接宣告失败。原因在于，mysqldump 输出的是一个单一的、流式的 SQL 文件，里面既没有清晰的事务边界标记，也没有记录任何校验位点。连接中断后重来，你根本无法确定“最后成功执行到了哪一条 INSERT 语句”。如果强行继续，结果不是数据重复写入，就是部分数据被跳过，留下一堆烂摊子。

用 mydumper + myloader 实现表级断点续传

那么，有没有更靠谱的方案？答案是肯定的。mydumper 的设计思路就很巧妙：它把整个数据库拆分成多个独立的文件——通常是每张表一个 .sql 文件，外加一个记录全局快照位点的 metadata 文件。而它的好搭档 myloader 则提供了 --resume 参数，能够自动跳过目标库中已经存在的非空表。这套组合拳，目前堪称 MySQL 生态中落地最稳健的断点续传方案。

• 备份阶段：执行 mydumper -h src -u user -p pass -B db1 -o /backup/db1/ --chunk-filesize=64。这里的 --chunk-filesize 参数是关键，它会按指定大小切分大表，避免单个文件过大，拖慢后续的恢复速度。
• 失败后检查：迁移中途如果失败，先别急着重来。去检查一下 /backup/db1/ 目录下，哪些 .sql 文件对应的表在目标库中已经存在，并且行数大致匹配（可以通过查询 information_schema.tables 来确认）。
• 重试恢复：确认后，使用 myloader -h dst -u user -p pass -B db1 -d /backup/db1/ --resume --threads=4 命令重试。加上 --resume 参数后，它会自动跳过那些已存在的非空表。
• 重要提醒：必须注意的是，--resume 的逻辑仅仅是判断“表是否存在且非空”，它并不校验表内的数据是否完全一致。对于大表，建议同时使用 --chunk-filesize 和 --enable-binlog 等参数，以避免对线上主库造成过大压力或导致主从延迟突增。

网络层加固：用 mosh 或 tmux + ssh -o ServerAliveInterval=30

光有应用层的续传能力还不够，我们得从根源上减少中断发生的频率。SSH 默认的超时机制对于动辄数小时的数据库 dump 操作并不友好，很容易因为 TCP 连接空闲而被中间的网络设备掐断。

• 优化 SSH 连接：不要使用默认的 ssh 命令，改用 ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=3 user@host。这相当于让客户端定期（每30秒）发送保活包，大大降低被意外断连的风险。
• 使用终端复用器：登录远程主机后，先启动一个 tmux 或 screen 会话，再在里面运行 mydumper。这样即使网络断开，进程也会在后台继续运行。重新连接后，只需一个 tmux attach 命令，就能无缝切回原来的操作界面和日志输出。
• 关于 mosh：虽然 mosh 对网络波动的容忍度更高，但它并不适用于典型的 MySQL 迁移场景。因为它不支持 SSH 端口转发，无法通过跳板机连接内网数据库；同时，其 UDP 协议不保证数据包顺序的特性，也不适合传输大容量的、顺序敏感的 SQL 数据流。

真正关键的不是“怎么续”，而是“怎么知道续对了”

这才是问题的核心。断点续传最大的风险，其实在于错误地判断了“成功”状态。举个例子：某张大表在导入到一半时失败，但目标库已经创建了对应的空表结构。此时若使用 myloader --resume，它就会因为“表已存在且非空”（实际上只有结构，没有完整数据）而跳过这张表，导致数据严重丢失。因此，人工核验或自动化的一致性检查，是绝对不能省略的最后一环。

• 行数快速比对：每次运行 myloader 前或后，可以写个简单脚本，用类似 ls /backup/db1/*.sql | sed 's/\.sql$//' | xargs -I{} mysql -h dst -Nse "SELECT COUNT(*) FROM db1.{}" 的命令，快速扫描一遍目标库所有表的行数，然后与源库 information_schema.tables 中的 table_rows 进行粗略对比。
• 关键表一致性校验：对于核心业务表，可以在源库导出前，执行 FLUSH TABLES WITH READ LOCK 并记录 SHOW MASTER STATUS 的 binlog 位置，以获得一个一致的快照点。数据恢复完成后，使用 pt-table-checksum 等专业工具进行行级别的数据一致性比对。
• 理解元数据限制：mydumper 生成的 metadata 文件里确实有 Started dump at: 时间戳，但这只是一个逻辑时间点，不等于 GTID 或精确的 binlog 位点。它不能直接用于构建主从关系或确保主从数据完全追平。

说到底，断点续传机制能挽救的是“流程”，但它挽救不了“数据一致性”。网络抖动往往只是表象，背后暴露的，常常是迁移前没有做好流量评估、压力测试以及完备的校验预案。准备工作做到位，才是避免踩坑的根本。