管理数据

一句话

你以为发布的难点是代码，其实真正撤不回来的是数据。这一章把前面十一章建立起来的「构建一次、随处部署、随时可回滚」拿到数据库面前重做一遍，发现有一半假设不成立：应用是无状态的、可以整包换掉，数据库带着状态、只能被增量地改、而且时间只朝一个方向走。本章给出的答案是三件事——把数据库纳入版本控制并以编号脚本增量迁移、把迁移做成非破坏性的、并与应用部署解耦、为流水线的每个阶段准备恰当而最小的测试数据。

Glossary · 术语表

坐标

本章属于《持续交付》Part III「交付生态」，紧接 Ch11（管理基础设施与环境）。它接住 Ch10「部署与发布」明确留下的那个缺口：蓝绿和金丝雀让代码的上线变得可撤回，可两套版本共用的那个数据库怎么办？同时它是 Ch2「配置管理」「一切纳入版本控制」的最后一块拼图——代码进去了、环境进去了，数据库也必须进去。下启 Ch13（组件与依赖）。现实对应物是今天的 Flyway、Liquibase、Rails / Django migrations、gh-ost、以及所有「零停机 schema 变更」的实践。

这章要解决什么

先看清楚这道题为什么和前面十一章都不一样。应用是无状态的，数据库是有状态的，这一个差别毁掉了三条你已经习以为常的性质：

• 「构建一次、随处部署」不成立。同一个应用制品可以原样丢进测试和生产；数据库不行——生产库里有真实数据，你只能就地增量地改它，而且每个环境的起始状态都不同。
• 「回滚 = 换回上一个制品」不成立。换回旧版应用是秒级、无损的操作；把数据库换回上一版则意味着两难：要么执行反向脚本（但被删掉的列里的数据已经没了），要么恢复备份（那就丢掉备份点之后所有人的写入，也就是把 RPO 直接扔出去）。
• 「随时可发布」被结构变更卡住。在一张几亿行的表上执行 ALTER TABLE，传统做法要重建整张表并持锁——量级是几十分钟到几小时，期间写入全部阻塞。于是「加个字段」这种小事，被排进了半年一次的停机窗口。

不解决会怎样，答案很具体：数据库成了整条流水线上唯一还靠手工、靠一个人的记忆、靠一张便条的环节。前十一章把构建、测试、环境全自动化了，上线那晚仍然是某位 DBA 登上生产库敲几条 SQL，敲完没人知道他到底敲了什么。团队于是不敢频繁发布，回到大批量、长间隔、高风险的老路——而这正是全书第一章要拆掉的东西。

核心内容，讲透

一、把数据库纳入版本控制：初始化 + 增量迁移

起点是 Ch2 那条规矩的延伸：数据库的一切也要能从版本库重建。分两半——初始化：建库、建 schema、灌入参照数据的脚本，让任何人在任何机器上一条命令得到一个空白但可用的库；增量变更：此后每次结构改动都不是「上去改一下」，而是新增一个编号的迁移脚本并提交到版本库。

机制很朴素，但正是它把数据库拉进了流水线：库里存一张版本表，记着自己当前处在第几号。部署工具读出这个号（比如 27），对照版本库里已有的脚本（到 31 号），把 28 到 31 依次执行，再把版本号写成 31。每个脚本配一个反向的 down 用于降级。本书成书时的代表工具是 dbdeploy 与 LiquiBase，Rails migrations 是同一思路最广为人知的实现，今天的 Flyway 亦然。

关键收益不在「自动化」四个字，而在于：同一批迁移脚本，在到达生产之前已经在开发机、提交阶段、验收环境、预生产上跑过许多次。上线那晚执行的不是一段没人见过的 SQL，而是今天已经成功跑过二十遍的脚本——数据库变更就此从「一次性事件」变成「被反复演练的例行动作」。

二、回滚：三条路，和「非破坏性迁移」这条硬规矩

这是全章最难、也最有价值的一节。本书给回滚数据库列了三条路，代价差别极大。

路 A：迁移前备份，出事恢复。最朴素，也是多数团队的默认答案。硬伤有二：丢数据——恢复到备份点意味着这段时间所有用户写入蒸发；慢——TB 级库的恢复通常是数小时量级，远超任何像样的 RTO。它只在「有停机窗口、库不大、且能接受丢这段数据」时成立。

路 B：写反向（down）脚本。能撤销结构，却撤不回信息：028_up 删掉了 legacy_addr 列，028_down 能把这一列加回来，却填不回里面原本的内容。这就逼出了本章最该记住的规矩——

迁移必须是非破坏性的（non-destructive）。要移除一个列，不要在同一次迁移里删掉它：先把数据复制到一张备份表（或干脆保留原列不用），确认新结构稳定运行若干个发布周期之后，再用一个单独的迁移真正删除。这样反向脚本才有东西可恢复。同一规矩的另一面是：改名等于删加——把 addr 重命名为 address，在数据库看来就是一次破坏性变更，旧版应用会当场找不到列。

路 C：不制造需要回滚的那一刻。这是本章最有远见的一段，也是下一节的主题。

三、把应用部署与数据库迁移解耦：兼容窗口与「扩展-收缩」

Ch10 留下的那道题在这里作答：蓝绿的两套环境通常共用同一个数据库，所以切流量那一刻，新旧两版应用必然同时对着同一个 schema 说话。想让部署可撤回就只有一个办法——让 schema 同时兼容新旧两版应用。本书的表述是「让数据库变更与应用变更相互独立、彼此兼容」；这套做法后来被 Danilo Sato 与 Martin Fowler 命名为 ParallelChange / expand-contract（扩展-收缩），今天已是零停机变更的默认解法。

核心是把「一步到位的结构切换」拆成一串各自可停可退的小步，中间保留一个兼容窗口——窗口里新旧两版应用都能正常跑。以「把地址从一个字段拆成结构化的几列」为例：

六步里最该注意的是它们是分开上线的：每一步都是一次独立、可回滚的部署，两步之间可以隔几小时也可以隔两周。①②③ 全是加法，代价只是磁盘和一点写放大；⑥ 是唯一不可逆的操作，而它发生在新路径已被真实流量跑过很久之后。另外注意 ① 里那句「可空、无默认」——在许多数据库上，给大表加一个带默认值的非空列会触发全表重写（PostgreSQL 直到 11 版才对不变默认值做了优化），一个看似无害的迁移就此变成长时间持锁。

本章还提到一条更重的解耦手段：用视图或存储过程给数据库包一层「公共接口」，应用只对接口编程，底层表结构改动时由接口层吸收差异。它确实降低耦合，代价是逻辑跑进了数据库、测试与版本管理都更难，本书对此保持克制。

四、共享数据库与编排式变更

上面所有招数都假设「这个库是我一个人的」。现实里最难的场景是多个应用共用一个数据库——本书称之为需要编排（orchestration）的变更：改一个列，得同时改三个团队的代码，还得让三次发布同时落地。这直接违背持续交付的地基（小批量、独立发布），于是本章的建议是把编排的需要减到最少：让每个应用拥有自己的数据，跨应用访问走明确定义的接口（服务或数据库视图），而不是让别人直接读你的表。实在拆不掉的，就必须把兼容窗口开到足够长——长到最慢的那个团队也完成了迁移。这正是 Martin Fowler 所说的集成数据库（integration database）反模式，也是后来微服务「每服务一库」主张的直接来源。

五、测试数据：三类数据，与「别拷生产库」

本章后半转向一个日常得多、却同样常年做错的问题：测试用的数据从哪来。先分清三类——参照数据（币种、国家、状态码，跟 schema 一起版本化）；测试专属数据（某个测试为验证自己而造的那几条记录）；应用一致性数据（为满足外键与业务约束而必须一并存在的周边记录）。混为一谈，就会得到那种「谁都不敢删」的巨型共享测试库。

最重要的一条反模式是：不要把生产库整个拷到测试环境。四条理由条条致命——太大（验收测试从几分钟涨到几十分钟，直接冲垮 Ch7 的十分钟提交阶段与 Ch8 的反馈节奏）；含真实个人数据（合规风险）；没人拥有它（一个人改了一条记录，别人的测试隔天莫名其妙变红）；它会腐化（生产数据里混着历史遗留的脏记录，测试却假设它们合法）。正解是每个测试造出自己需要的最小数据集，并尽可能通过应用自己的 API 来造——这样 schema 演化时测试数据自动跟着演化，不会退化成一堆写死的 INSERT。

让测试与数据解耦，本章给了三种办法，优劣分明：测试隔离（每个测试用自己独有的键前缀 / 账号，互不可见，最推荐）；自适应测试（先查询当前状态，再据此断言或自建前置数据）；测试排序（让测试 B 依赖测试 A 留下的数据）——最后这种本书明确反对：无法并行、无法单独重跑，一个失败引发一串失败。

关键权衡与选型

表 1 · 数据库出了问题怎么退回来：三条路的真实代价

表 2 · 常见 schema 变更的危险等级与安全做法（含具体量级参考）

表 3 · 让测试不再互相踩：三种解耦策略

表 4 · 数据库归谁：独占 vs 共享（编排式变更的成本）

四张表之外，本章真正的总判据同样只有一句，可以当场自查：你上一次生产发布，如果十分钟后决定撤回，数据库这一侧需要做什么？答案是「什么都不用做，只换回旧版应用」，说明你走在这一章的路上；答案是「叫 DBA 起来恢复备份」，那么无论用了多先进的部署工具，你的发布仍然是不可逆的。

为什么重要 / 落到真实系统

这一章是全书里被后续十五年验证得最彻底的一章。Flyway 与 Liquibase 把「编号迁移脚本 + 库内版本表」做成了行业标配，Rails、Django、Entity Framework 把它内置进了框架；gh-ost、pt-online-schema-change、pg_repack 这类在线变更工具，解决的正是本章点名的障碍——大表 ALTER 会长时间持锁；扩展-收缩则成了任何一份「零停机发布」清单上的第一条。反过来，本章预警的两个坑也原样留存至今：共享数据库仍是微服务拆分中最难的一刀，「拷一份生产库当测试数据」仍是多数团队的默认起手式。

面试与架构评审里这一章的问法很固定，而能拿分的答案从来不是工具名：数据库变更进版本库吗，还是发布当晚现敲？上一次发布若要回滚，数据库这边怎么办？给一张一亿行的表加个非空字段，你打算怎么加？测试环境的数据是从生产拷的吗？最后一问尤其能分辨人——答「是」的团队，几乎必然同时有着慢而不稳的验收测试。

易错点与争议

• 把「写了 down 脚本」当成「能回滚」。反向脚本几乎从不在流水线上被执行、因而从不被测试；真出事那一刻你才第一次运行它。更根本的是它撤不回信息——被删的列加回来是空的。可回滚性来自非破坏性迁移与兼容窗口，不来自 down 脚本。
• 把迁移脚本当普通代码改。已发布的迁移脚本是不可变的历史：直接修改 028 号，会让已经执行过它的环境和没执行过的环境永久分叉。要修正只能追加 032 号。
• 只测「迁移能不能跑通」，不测「迁移要跑多久」。在开发机上 200 行的表里瞬间完成的 ALTER，在生产的两亿行表上可能锁两小时。迁移的执行时长本身就是一项必须在类生产数据量上验证的指标，这也是容量测试环境需要真实量级数据的原因之一。
• 忘了「回滚应用」也要求前向兼容。大家都记得新版应用要能读旧数据，却常忘了反过来：旧版应用必须能在新 schema 上继续跑，否则一旦回滚就是全站故障。所以扩展-收缩里那些「多余」的中间步骤，买的正是这个。
• 以为生产数据脱敏后就万事大吉。脱敏解决了隐私，没解决另外三个问题：仍然太大、仍然没人拥有、仍然携带历史脏数据。它是合规底线，不是测试数据策略。
• 时代局限。本书成于 2010 年，早于云托管数据库、CDC（变更数据捕获）与 gh-ost 一类在线变更工具的成熟，因此对「怎么在不锁表的前提下改大表」着墨不多；书里默认的关系型世界也不覆盖 schemaless 存储——不过后者只是把 schema 从数据库挪进了应用代码，兼容窗口的问题一点没变，只是更隐蔽。
• 争议：数据库到底该不该有「down 脚本」？一派认为该有，聊胜于无；另一派（今天更主流，Flyway 的默认姿态即偏向此）认为只向前不向后——出了问题就再发一个向前修复的迁移，因为向前的路径是被测试过的，向后的不是。判断标准很实际：你的迁移如果本来就是非破坏性的，向前修复几乎总能走通；如果不是，down 脚本也救不了你。

要点