92 lines
4.8 KiB
Markdown
92 lines
4.8 KiB
Markdown
# RailwaySystem 数据库 V2 应急回滚指南 (Round 1 修订版)
|
||
|
||
> **技术基线**：KingbaseES V009R003C018 (`schema=public`)
|
||
> **回滚目标**：安全撤销 V2 数据库结构变更，将数据模型与物理约束 100% 精确还原至 Phase 0.5 历史基线。
|
||
|
||
---
|
||
|
||
## 1. 核心架构升级：解耦结构与数据
|
||
|
||
在 Round 1 审查中，彻底废除了使用 `CREATE TABLE ... AS SELECT * FROM bak_v1_*`（CTAS）推断历史结构的危险方案：
|
||
|
||
```text
|
||
┌─────────────────────────────────────────────────────────┐
|
||
│ Phase 0.5 精确物理结构 (表定义/列类型/PK/FK/UNIQUE/触发器) │
|
||
│ 来源: rollback/000_phase05_exact_schema.sql │
|
||
└───────────────────────────┬─────────────────────────────┘
|
||
│ (先精确重建物理表结构)
|
||
▼
|
||
┌─────────────────────────────────────────────────────────┐
|
||
│ Phase 0.5 真实数据 (唯一教师行 + 各表数据) │
|
||
│ 来源: 001 备份生成的 bak_v1_* 快照表 │
|
||
└───────────────────────────┬─────────────────────────────┘
|
||
│ (再通过 INSERT INTO 导入数据)
|
||
▼
|
||
【Phase 0.5 绝对还原】
|
||
```
|
||
|
||
- **`000_phase05_exact_schema.sql`**：作为唯一的物理结构基准，确保回滚后恢复所有 24 个旧外键、7 组旧业务唯一约束、NOT NULL、DEFAULT、IDENTITY 序列以及 9 个 `update_time` 触发器；
|
||
- **`bak_v1_*` 快照表**：仅承担纯粹的“数据暂存”职责。
|
||
|
||
---
|
||
|
||
## 2. 回滚脚本执行顺序
|
||
|
||
若在测试迁移或灰度验证阶段发现重大异常，需按照以下严格顺序执行回滚流水线：
|
||
|
||
```text
|
||
步骤 1: 执行 001_rollback_new_tables.sql
|
||
-> 显式解除外键依赖，安全下线并 DROP 掉 V2 新增的 8 张业务表
|
||
|
||
步骤 2: 执行 002_rollback_modified_tables.sql
|
||
-> 基于 000_phase05_exact_schema.sql 的精确结构重建 13 张表，并从 bak_v1_* 物理快照还原数据，严格断言教师数据为 1 行
|
||
|
||
步骤 3: 执行 003_restore_legacy_score.sql
|
||
-> 基于 000_phase05_exact_schema.sql 的精确结构重建 train_score_info 及 3 个历史外键与唯一约束
|
||
|
||
步骤 4: 人工核验 Phase 0.5 状态
|
||
-> 执行 000_preflight.sql 校验基线恢复，确认 14 张表、触发器与约束 100% 吻合
|
||
```
|
||
|
||
---
|
||
|
||
## 3. 强前置依赖与数据来源声明
|
||
|
||
> [!CAUTION]
|
||
> **回滚操作必须满足以下前置条件：**
|
||
|
||
1. **依赖 001 备份快照**：
|
||
- 步骤 2 与步骤 3 的数据还原依赖迁移前由 `001_backup_current_schema.sql` 生成的 `bak_v1_*` 快照表。
|
||
- 若 `bak_v1_*` 表意外被删，**严禁盲目执行数据还原语句**。
|
||
2. **唯一教师数据的物理还原**：
|
||
- 教师主档 `train_teacher` 的数据通过 `INSERT INTO train_teacher SELECT * FROM bak_v1_train_teacher;` 完整回灌。回滚脚本会严格校验恢复后的教师行数必须等于 1。
|
||
3. **事务安全性**：
|
||
- 每一个回滚 SQL 文件内部均由显式 `BEGIN ... COMMIT` 包裹，出现任何错误自动整单回滚，不产生中间半回滚状态。
|
||
|
||
---
|
||
|
||
## 4. 必须人工介入确认的场景
|
||
|
||
### 场景 A：V2 阶段已产生新业务数据
|
||
如果系统在执行 V2 DDL 之后，业务端或测试端已经在 `train_enrollment`、`train_lesson`、`train_student_score` 等表中写入了新数据：
|
||
- **直接执行回滚将导致这些新业务数据彻底物理清除！**
|
||
- **必须人工介入**：先通过数据导出工具将 V2 新增业务数据导出为 CSV/JSON 归档，确认业务无异议后方可执行回滚。
|
||
|
||
### 场景 B：bak_v1_* 备份表意外缺失
|
||
若 `bak_v1_*` 表不存在：
|
||
- 必须暂停脚本执行；
|
||
- 从数据库物理备份集（如 `sys_backup` / 逻辑转储快照）中恢复 14 张旧表数据。
|
||
|
||
---
|
||
|
||
## 5. 回滚后验收确认 Checklist
|
||
|
||
回滚完成后，在数据库客户端中直接运行 `000_preflight.sql` 即可自动化完成全量反向验收：
|
||
|
||
- [ ] 1. 运行 `000_preflight.sql` 成功输出 `[Preflight-PASS]`；
|
||
- [ ] 2. 确认已无任何 V2 独有表（如 `train_plan_course` 等）；
|
||
- [ ] 3. 确认旧表 `train_score_info` 已恢复，且具备旧外键；
|
||
- [ ] 4. 确认 `train_teacher` 精确包含 1 条数据，且旧字段 `t_department` 存在且非空；
|
||
- [ ] 5. 确认 9 个旧触发器全部重新挂载生效；
|
||
- [ ] 6. 确认系统表 `sys_*` 完好无损。
|