这次升级差点翻车
上周六凌晨两点到六点，我们把 MySQL 5.7 升到了 8.0，一百四十二张表，最大单表约三百八十万行，目标实例 8 核 32G，走的是 mysqldump 全量导出加主从切换，窗口卡死四小时，听起来不复杂，做起来全是毛刺，运维老张守着备份校验和回滚脚本，新同事小陈敲导出导入命令，DBA 老李盯着主库延迟、线程状态和磁盘队列，我在中间盯业务侧停写确认，本来以为这种同版本链路内的升级，最危险的是导入耗时和字符集错乱，结果真正给我一巴掌的是一条停写通知后还挂着的长事务，十一分钟不提交，把整个切换节奏硬生生拖住，最后只能回滚重做，窗口差点被啃穿。
文章配图，仅供参考 周三预演骗了人
周三下午三点那次预演，太顺了，顺到我现在回想都觉得不对劲，那天业务库是影子环境，连接池被我们掐得很干净，mysqldump 导出三百八十万行的大表、传文件、目标 8.0 导入、账号权限核对、sql_mode 检查、保留字检查、从库追 binlog，每一步都像按表走，老张还把回滚脚本跑了两遍，确认旧 5.7 实例重新挂回 VIP 后应用能正常建连，小陈把导入命令里的 single-transaction、set-gtid-purged、routines、events、triggers 这些参数逐字过了一遍，老李把慢查询、buffer pool、redo、连接数和复制延迟的监控图都摆出来，可预演环境里没有财务系统那条凌晨批量补账会话，也没有运营侧临时挂着的查询窗口，所以我们量到的是数据搬迁时间，没量到组织配合里的人肉阻塞，这事儿不能怪开发不配合，只能怪我把停写当成了开关，没把它当成一张需要逐 IP、逐账号、逐连接核对的封锁线。
2025 年那次更狼狈
说起来也不是第一次踩坑，二零二五年我们做过一次同构迁移，当时耗时八小时，最后把日志盘写满爆盘，原因现在看很低级，没提前关目标库 binlog，导数据时每一批 insert 都被记一遍日志，磁盘水位从六十多一路冲到百分之百，业务恢复时间从计划的四小时拖到八小时，老张那时候还在边扩容边清日志，老李一边暂停导入一边追主从，我在群里被业务负责人追着问还能多久，那种盯着磁盘剩余空间往下掉、却不敢贸然 kill 会话的感觉，比这次长事务堵门还难受，所以这次目标 8.0 实例初始化后，我们先核对了 log_bin、sync_binlog、innodb_flush_log_at_trx_timeout、慢日志阈值和自动扩容策略，导入阶段临时关闭 binlog，导完再按主从切换要求恢复配置，听起来像是被旧事故训练出来的肌肉记忆，其实就是花钱买疼，疼一次记一次。
凌晨两点最怕假停写
到了周六凌晨，问题不是从命令开始的，是从“已经停写”这四个字开始的，两点整业务侧确认停写，小陈先在旧 5.7 主库上做全量导出，老张核对备份文件大小和校验值，老李看长连接、锁等待和未提交事务，我这边盯着应用群里的确认消息，前面十几分钟很稳，导出文件按表分块生成，目标 8.0 实例导入也没报字符集问题，可等到准备切主从时，老李突然说库里还有一个会话时间超过十一分钟，状态不是执行大 SQL，而是 sleep，线程拿着事务没提交，关联表上还压着一把元数据锁，后面的 DDL 和连接切换全被堵住，那一刻我最直观的感受不是紧张，是烦，因为预案里写了停写，却没把 sleep 会话里残留事务当成一级风险，群里喊人没人立刻回，电话打到值班同学那边才知道，财务批量程序虽然不再发新请求，但旧连接没有正确归还，事务上下文还挂着。
我原以为停了就平
我原以为停写后流量归零，主从切换就能按预演平滑走完，结果数据库里真正要命的不是还在跑的高峰流量，而是一个没人看见、没有提交、也没有回滚的旧事务，它不喊不叫，却能让后面的校验、切换、域名和 VIP 变更都不敢继续，当时距离窗口结束还剩不到一小时四十分钟，老张主张先回滚，把旧 5.7 主库重新接回去，等业务侧杀干净连接后重做，小陈手放在 kill 命令上没敢敲，老李翻 information_schema.innodb_trx 和 processlist，把账号、来源 IP、事务开始时间、锁等待关系全贴到群里，我同意回滚，硬切只会把风险从一个长事务放大成全链路未知状态，回滚动作反而干净，旧实例还活着，备份还刚校验过，应用切回去后几笔补偿请求能正常写入，这才给第二次切换留下余地。
域名这行也吃这套烂账
我平时管域名，看着跟数据库升级不挨着，其实脏活很像，域名转出、注册商迁移、DNS 改 NS、whois 邮箱替换、续费窗口卡边界，表面都是点一下确认，底下全是残留记录、缓存 TTL、注册局延迟和客户邮箱失效，二零二三年有个四声 com 要从海外注册商拉回国内，客户说邮箱已经停用，我原以为拿到转移码就能走，结果注册局锁、注册商隐私保护、客户管理员离职三件事叠在一起，拖了六天，最后还是旧邮箱服务商临时恢复一天才收到确认信，做投资久了就知道，最贵的不是续费差价，是你以为自己已经掌控全局，实际还有一条十一分钟的老事务挂在线上，像那种买家说今晚付款、卖家说已经 push、中介平台却没解除锁定的单子，三方都觉得自己动作完成，资产就是过不去。
第二次切换才像人话
第二次重做时我们没再信口头停写，先让业务侧把应用连接池缩到零，再按账号和来源 IP 核对 processlist，财务那台固定机器的连接单独 kill，批处理进程直接停掉，运营查询账号收回权限，小陈重新导出时补了锁与事务检查，老张把回滚脚本放在终端第一屏，老李把主从延迟告警阈值压到三秒，我在切换表上加了一项“无 sleep 长事务超过两分钟”，这条不是从官方文档抄的，是周六凌晨被那条十一分钟的连接逼出来的，后面导入、建账号、验权限、挂从库、追 binlog、切 VIP、放开应用连接，全部在五点四十之前完成，留了二十分钟给核心下单、支付回调、后台查询和定时任务验证，六点关窗时没有报错，监控里只有一小段连接抖动，没影响业务写入。
别把预案写成许愿单
这次之后我不信那种漂亮预案了，什么停写、导出、导入、切换、验证，一列五个步骤，看着清楚，实际每个步骤都要挂具体证据，停写要看 processlist 和 innodb_trx，导出要看文件校验值和表数量，导入要看报错日志和每张表行数，切换要看复制延迟和 GTID 状态，验证要拿真实业务接口跑写入，而不是群里一句“可以了”就往下冲，老张的备份校验和回滚脚本救了节奏，小陈虽然第一次参加这种凌晨操作，但每条命令执行前都先贴参数，没有自作主张加并行，老李最关键，他没只看 QPS，而是盯着事务、锁和复制状态，否则那条 sleep 会话可能会被当成空闲连接放过去，我们这次最大的幸运不是技术方案多高级，是旧库可回退，备份刚校验，窗口还剩时间，人也都在线。
明年再升级，我会先杀连接
下次再做 5.7 到 8.0，或者任何看着像搬数据的迁移，我第一件事不是讨论 mysqldump 还是物理备份，也不是争论 8 核 32G 够不够，而是先把停写定义到连接级别，哪些账号必须断开，哪些 IP 必须封禁，哪些 sleep 事务超过多久直接 kill，DDL 前由谁复核，kill 不掉的会话走哪条升级路径，全部写死，数据库迁移这事儿，三百八十万行不算大，一百四十二张表也不算多，四小时窗口足够让熟手犯错，真正的坑从来不在版本号上，在人以为“应该没连接了”的那一秒。 （编辑：站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
14年血泪史，跨端模型一次搞定全平台分类？
14年血泪史：索引碎片率超30%，搜索直接跪了
他不造车不发火箭，只重构全球域名资源逻辑
站长技术跨界融合：6年域名投资实战速递