yuetsh
fb22b7d49f
docs(阶段5): 用生产快照跑完整切换演练
演练用 compose.debian.yml **本身**在本机 Docker 里跑，不是简化版。
数据是 2026-08-07 的 pg_dumpall 快照：1710 用户 / 956 题 / 123140 提交。
## 出口标准达成
停旧栈 11s，起新栈 34s（镜像预先构建好），全链路验证约 2 分钟 ——
**停机不到 1 分钟**，远在 30 分钟内。真正的时间风险在构建镜像（首次约 5 分钟），
所以手册里第一条就是「镜像必须在停机窗口之前构建好」。
验证到位的：首页、站点配置、题目列表、标签、公告、登录（argon2 新哈希和
Django pbkdf2 旧哈希都支持）、个人页、排行榜、后台四个接口、判题机自动注册，
以及**完整判题**（提交 Python A+B → AC，1.2 秒，两个测试点全过）。
## 两件原以为要做、实测不用做的事
- **不需要任何 DDL**：生产 dump 和新后端在用的库逐列对比，两边都是 278 列，
零差异。新后端直接跑在现有结构上。
- **不需要重置序列**：我在 phase3-coverage.md 里记的那条「切换必做：重置序列」
**是错的**，来自我手工按显式 id 导入、又没补 setval 的本地库。真实的
pg_dumpall 带 30 条 setval，且把快照里所有序列和 max(id) 逐个对过，错位 0 个。
已在原文档上标注更正，没有删掉原文 —— 错误结论本身也是信息。
## 回滚保证已实测
新栈跑完登录、提交、判题之后，再和生产 dump 比一次结构：逐列一致，零差异。
加上数据目录布局照抄旧后端，回滚 = 停新栈 + 起旧栈，约 20 秒，不动任何数据。
（未实测的部分也写明了：本机没构建旧 Django 镜像，「起旧栈」这一步没跑过。）
## 演练抓到的真问题
**pg_dumpall 备份会覆盖数据库口令。** 恢复完快照，新后端立刻报
`password authentication failed` —— 因为 dump 里带
`ALTER ROLE onlinejudge ... PASSWORD 'md5…'`，把角色口令覆盖成了备份时生产的那个。
正常切换不受影响（根本不恢复备份），但灾难恢复时这一条不写下来，
现场会被一个看起来毫不相干的报错卡住。
**恢复备份前必须先停应用**，否则 dump 里的 DROP DATABASE 失败。演练时因为
目标库是空的，数据照样进去了 —— 那是运气，目标库有数据就是满屏主键冲突。
## 镜像体积没达标，写明了原因
api 镜像 487MB，设计文档写的是「数十 MB」。一半以上（269MB）是 clang-format
拖进来的 LLVM，光 libLLVM.so 就 124MB。旧 Python 镜像同样装了 clang-format，
所以新镜像仍明显更小，但当初估「数十 MB」时没把它算进去。
瘦身路径也记了（换静态 clang-format 可砍 265MB），暂不做。
## 清理
演练在 data/postgres 留下了一份完整的生产数据副本，含 1710 名学生的
raw_password 明文列，已删除。手册里留了提醒 —— 那不是测试数据。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-08 02:13:59 -06:00
..
2026-08-06 22:42:39 -06:00
2026-08-08 02:13:59 -06:00
2026-08-06 20:08:53 -06:00