数据库升级前，先准备一份能真的执行的回滚清单

数据库升级这种事，很多团队会认真写升级步骤，却不认真写回滚步骤。可真正到了线上，最能决定你心态的往往不是“怎么升”，而是“如果升坏了，能不能稳稳退回来”。

2016 年我在处理 MySQL、MongoDB 这类服务时，越来越不相信“应该没问题”这种判断。我更信一份已经想清楚的回滚清单。

一份回滚清单至少要回答四件事

我后来给自己列的清单，最少要把下面四个问题写清楚：

• 回滚时依赖哪份备份，备份放在哪里
• 触发回滚的条件是什么，谁来拍板
• 回滚以后怎么验证业务已经恢复
• 如果回滚也失败了，下一层兜底动作是什么

没有这四件事，所谓回滚计划常常只是心理安慰。

“先备份”这句话其实不够

很多人会说升级前先备份，这当然没错，但还不够。
真正有用的是你要知道：

• 备份是全量还是增量
• 恢复它需要多长时间
• 恢复过程中业务是否要停写
• 恢复出来的数据点会不会丢最近几分钟操作

这些问题如果不提前想，等事故真的发生，再去问已经来不及。

回滚触发条件不能太模糊

我见过一种最危险的状态：大家都觉得“再看看，也许一会就好”。
结果原本可以十分钟内止损的故障，被拖成了一个小时。

所以我更喜欢在升级前就写下明确条件，比如：

• 主流程接口连续报错
• 从库同步明显异常
• 关键查询耗时翻倍且持续不恢复
• 新版本兼容脚本导致写入失败

条件写清楚，不是为了悲观，而是为了让团队在压力下还能保持判断一致。

回滚之后一定要做业务验证

回滚成功不等于业务恢复。
服务启动了、数据库能连上，只说明技术动作做完了一半。真正要看的，是核心业务链路有没有恢复：

• 登录还能不能正常
• 订单或内容写入是否正常
• 后台查询是否恢复到升级前水平

如果没有业务验证，团队很容易在“数据库已经起来了”的错觉里提前散场。

我后来对升级的态度

不是不能升级，也不是每次都要如临大敌，而是只要涉及数据层，就必须把“退出策略”设计得和“进入策略”一样认真。
升级步骤是把你送到新世界的路，回滚清单则是防止你迷路时回不来的绳子。

有了这根绳子，很多线上动作反而会更稳。