用增量同步减少停机时间

停机时间长的迁移，问题通常出在全量拷贝上：几百 GB 的库，导出加导入动辄五六个小时，业务全程不可用。增量同步的思路，是把耗时的全量搬到停机窗口之外，窗口里只做收尾。 原理拆开看 MySQL 开启 binlog（二进制日志）之后，每一次写入都会记成日志。迁移就变成两段：先在业务运行时完成一次全量拷贝，记下日志位点；之后新库回放 binlog，把全量之后产生的写入一条条追上来。binlog 文件默认在数据目录下，名字形如 mysql-bin.000023；全量导出带 --master-data=2 参数，位点会写进备份文件，回放起点一目了然。追平之后，新老库内容一致，此刻切换应用配置，业务几乎无感。 时间账算一下 假设库有 500GB：全量导出加导入约 4 小时，这 4 小时业务照常跑；binlog 回放的延迟随追赶缩小，稳定后只剩秒级；最终切换只做三件事——停写入、追平最后几秒的增量、改配置重启，全程 5 分钟上下。同样的库，停机从 4 小时压到 5 分钟，差距全在结构上。实际能压到多短，还取决于增量从几点开始追：全量做得越晚、追赶期越长，切换时剩下的尾巴越小。 怎么落地 自建环境用 MySQL 主从复制最省事，新库作为从库自动回放主库的日志；不方便开复制的，用工具按位点导出增量文件逐段补。云上的方案多数是快照加日志恢复，原理相同。MySQL 5.6 之后建议开 GTID 复制，位点自动管理，主从切换不用手算文件名和偏移量。 三个注意点：全量导出带 --single-transaction 参数，避免锁表影响业务；binlog 格式建议用 ROW，回放最稳；切换前确认延迟真正归零，主从方案里看 show slave status 的 Seconds_Behind_Master 是不是 0。追赶期间延迟迟迟不降，先查新库配置是不是比老库差太多，机器弱，追数据只会越追越远。 增量同步把迁移从"找一个通宵"变成"找五分钟"。值不值得搭这套结构，看你那台库有多大、业务能不能停。