数据库迁移的停机窗口控制

整套迁移计划里最紧的一段，是数据库的停机窗口：窗口越短，业务损失越小。控制窗口只有一个思路——能提前做的都提前做，窗口里只留必须做的动作：窗口开始前几分钟，先把消息队列的消费者停掉，积压任务等新库就位再放行，避免切换瞬间写入打架。 准备：窗口外完成全量 全量导出和导入都放在停机之前完成： mysqldump -uroot -p --single-transaction --master-data=2 dbname > dbname.sql --single-transaction 对 InnoDB 表导出时不锁业务，白天照常跑；几十 GB 的库导入要好几个小时，也提前做完。动手前用 df -h 检查两端磁盘：导出文件加导入副本要占约两倍库容，空间不足先扩。演练时记下各步耗时，窗口承诺按实测加五成余量去报。 窗口内三步走 第一步，老库设只读，挡住新写入：set global read_only=1; 此刻应用的写入会开始报错，这就是窗口的起点，全组人到位。 第二步，补增量。从全量导出时刻到现在，新产生的数据量通常不大，再跑一轮增量导出导入即可追平。这一步是窗口耗时的大头，提前演练过就知道大概几分钟。 第三步，改应用配置里的数据库地址，重启服务，再放开只读：set global read_only=0; 验证与收尾 应用起来后立即验证三件事：登录能写 session、下单能写库、自增 ID 没有回退。全部通过，窗口结束，发完成通知。表行数抽核：SELECT COUNT(*) 对比几张核心表两边的数量，配合最大自增 ID 核对，数字一致才算真追平。 算一笔账：一个 50GB 的库，全量提前跑完，增量补齐加配置切换实测能压到十分钟以内；不做准备直接搬库，同样的库要停三四个小时，差距全在准备上。 常见报错是切换后中文乱码，原因是新老库字符集不一致，导入时带上 --default-character-set=utf8mb4 可以避免。 窗口控制在演练里，不在计划里。正式切换前拿测试库完整走一遍，拿到真实耗时，窗口才有底气对外承诺。