修复(08-23-isolated-backup-restore-drill): 消除影子库就绪竞态
这个提交包含在：
@@ -120,13 +120,15 @@ Attempt 4 在 `dump_list=PASS/0` 后、实际 restore apply 前以 `restore_targ
|
||||
|
||||
1. 删除 runner 的“首次 `pg_isready` 成功即通过”判定。`pg_isready` 最多可作为诊断，不能成为允许 restore 的充分条件。
|
||||
2. `dump_list` 保持不连接目标数据库的独立阶段；其成功只证明 custom dump 目录可解析，不计入数据库稳定就绪次数。
|
||||
3. `target_confirmation` 在最多 60 次、每次间隔 1 秒的有界窗口内执行真实 `SELECT current_database()`。每次查询退出码非零时把连续成功计数重置为 `0`；查询成功且数据库名精确等于本轮 shadow 目标时累计，只有连续两次成功才 `PASS`；查询成功但名称不匹配立即失败，不继续重试。
|
||||
4. 脱敏输出增加 `target_confirmation_exit_code`、`target_name_match=yes|no|NOT_RUN`、`target_confirmation_attempt_count` 和 `target_confirmation_success_streak`。退出码取最后一次实际查询的非负整数；未执行为 `NOT_RUN`。错误类别区分 `TARGET_QUERY_NONZERO` 与 `TARGET_NAME_MISMATCH`，不得输出查询文本、数据库名、路径、凭据或原始 stderr。
|
||||
5. 稳定就绪函数必须定义在被渲染 runner 中；合同从 rendered runner 提取或直接驱动该同一实现，不得在 fixture 外围另写一套更宽松或更稳定的等待逻辑。fixture 自身如需等待，也必须通过同一实现进入后续真实脚本双路径回归。
|
||||
6. 回归至少覆盖：首次查询失败后连续两次成功可继续；一次成功后失败会重置 streak；数据库名错配立即失败；查询持续非零在第 60 次后失败；每条失败路径的 apply 保持 `NOT_RUN`、诊断先于清理且残留为 `0`；原有 dump、restore 双路径、身份、migration、附件和敏感输出合同继续全绿。
|
||||
7. 禁止用固定长 sleep、增加 ARM 特例、降低连续成功次数、跳过名称精确比较或只修改合同夹具来修复。若相同实现的本地合同通过而 ARM 仍在该阶段失败，保留环境差异 finding，依据新退出码和尝试计数继续调查，不现场放宽。
|
||||
3. `target_confirmation` 在容器内显式通过 TCP 回环 `127.0.0.1` 执行真实 `SELECT current_database()`，不用默认 Unix socket。官方 PostgreSQL 镜像的 initdb 临时服务器不监听 TCP，而正式服务器监听容器内回环；因此 TCP 成功是排除临时初始化服务器的结构性判据。`--network none` 不影响容器自己的 loopback，实际 restore 仍可继续沿现有 socket 路径，不修改 `scripts/restore-db.sh`。
|
||||
4. TCP 目标确认使用最多 60 次、每次间隔 1 秒的有界窗口作为额外保险。每次查询退出码非零时把连续成功计数重置为 `0`；查询成功且数据库名精确等于本轮 shadow 目标时累计，只有连续两次成功才 `PASS`；查询成功但名称不匹配立即失败，不继续重试。连续成功不是排除临时服务器的唯一依据，不能移除 TCP 回环判据后单独保留时序启发式。
|
||||
5. 脱敏输出增加 `target_confirmation_exit_code`、`target_name_match=yes|no|NOT_RUN`、`target_confirmation_attempt_count` 和 `target_confirmation_success_streak`。退出码取最后一次实际查询的非负整数；未执行为 `NOT_RUN`。错误类别区分 `TARGET_QUERY_NONZERO` 与 `TARGET_NAME_MISMATCH`，不得输出查询文本、数据库名、路径、凭据或原始 stderr。
|
||||
6. 稳定就绪函数必须定义在被渲染 runner 中；合同从 rendered runner 提取或直接驱动该同一实现，不得在 fixture 外围另写一套更宽松或更稳定的等待逻辑。fixture 自身如需等待，也必须通过同一实现进入后续真实脚本双路径回归。
|
||||
7. 实施前审计 runner 合同的每个覆盖机制，区分“直接执行跟踪脚本/校验器”“从 rendered runner 提取同一实现”“只做静态结构断言”和“合同自行重写等价逻辑”。最后一类必须消除或登记为明确限制，不能以组件测试通过推断未执行的 runner 编排行为。
|
||||
8. 回归至少覆盖：Unix socket 可用但 TCP 仍失败时不得通过；首次 TCP 查询失败后连续两次成功可继续；一次成功后失败会重置 streak；数据库名错配立即失败；查询持续非零在第 60 次后失败；每条失败路径的 apply 保持 `NOT_RUN`、诊断先于清理且残留为 `0`；原有 dump、restore 双路径、身份、migration、附件和敏感输出合同继续全绿。
|
||||
9. 禁止用固定长 sleep、增加 ARM 特例、降低连续成功次数、跳过 TCP 回环或名称精确比较、只修改合同夹具来修复。若相同实现的本地合同通过而 ARM 仍在该阶段失败，保留环境差异 finding，依据新退出码和尝试计数继续调查，不现场放宽。
|
||||
|
||||
本节只是待审设计，不构成修改 runner、连接 ARM 或执行 Attempt 5 的授权。修复通过后仍须提交可追溯变更、重新选择当时最新批次、重跑只读身份探针、重新渲染并核对候选 SHA-256，再单独申请 Attempt 5 实际恢复。
|
||||
本节已于 2026-08-25 获准仅在本地实施和回归；授权不包含连接 ARM 或执行 Attempt 5。修复通过后仍须提交可追溯变更、重新选择当时最新批次、重跑只读身份探针、重新渲染并核对候选 SHA-256，再单独申请 Attempt 5 实际恢复。
|
||||
|
||||
## 清理与回滚
|
||||
|
||||
|
||||
@@ -111,17 +111,18 @@
|
||||
- [x] Attempt 4 runtime、临时 root 入口和普通用户上传暂存均清理为 `PASS/0`；按预先裁决规则转入本地合同路径与 ARM 实际环境的只读差异调查，不直接修补 runner 或创建 Attempt 5。
|
||||
- [x] 只读差异矩阵与本地精确复现收敛到 PostgreSQL 初始化就绪竞态：合同夹具等待连续两次真实查询，runner 仅等待首次 `pg_isready`；本地稳定数据库上的同一 target query 为 `PASS/0`，ARM 所有临时对象复核残留 `0`。
|
||||
- [x] Attempt 4 后正式归档只读探针与执行前为同一构建和同一 manifest 脱敏摘要，run id 配对、产物 SHA-256、24 小时新鲜度均通过；探针入口与暂存残留 `0`，正式归档内容级零修改已补证。
|
||||
- [ ] 演练后腾讯云生产 `/ready` 尚未独立补证；须记录正常状态和 12 位构建前缀，不能由 ARM timer、归档探针或清理 PASS 代替。
|
||||
- [ ] 修复与任何 Attempt 5 尚未批准；先审阅 `design.md` 的“PostgreSQL 稳定就绪修订提案”，仅批准后才开始以下本地工作。
|
||||
- [x] 演练后腾讯云生产 `/ready` 已由执行方沿既有只读路径补证：状态 `PASS`、12 位构建前缀 `7b86ffb3c9ef`，与演练前一致；未记录地址或原始响应。
|
||||
- [x] 用户已批准仅在本地实施和回归 PostgreSQL 稳定就绪修复；该批准不包含连接 ARM 或执行 Attempt 5。
|
||||
|
||||
### Attempt 5 前仅本地修复计划（待批准）
|
||||
### Attempt 5 前仅本地修复结果
|
||||
|
||||
1. 在跟踪 runner 中以最多 60 次、间隔 1 秒、连续两次真实 `SELECT current_database()` 成功且名称精确匹配，替换首次 `pg_isready` 即通过逻辑；名称错配立即失败，查询非零重置连续成功计数。
|
||||
2. 增加 target query 退出码、名称匹配、尝试次数和连续成功次数的 allowlist 诊断，区分查询非零与名称错配；私有原始日志、失败先诊断后清理和零残留边界不变。
|
||||
3. 让可复跑合同直接驱动 rendered runner 中同一稳定就绪实现；删除 fixture 外围与 runner 不同源的稳定化旁路。
|
||||
4. 补齐首次失败后恢复、streak 重置、名称错配立即失败、永久查询失败有界退出四类回归，并复跑真实 `restore-db.sh` Docker stdin/host-file、源/副本身份、dynamic migration、附件安全、敏感输出和清理合同。
|
||||
5. 确认 `scripts/restore-db.sh` 字节未改，运行 task、Trellis、process、docs、敏感扫描和空白门禁；通过后以中文提交引用本 task。
|
||||
6. 本地修复阶段不连接 ARM、不生成或安装 Attempt 5 现场入口。提交后重新选择最新批次并执行只读探针、重新渲染候选和核对 SHA-256；实际恢复须再次单独批准。
|
||||
- [x] 在跟踪 runner 中以容器内 TCP 回环 `127.0.0.1` 的真实 `SELECT current_database()` 作为结构性就绪判据，并以最多 60 次、间隔 1 秒、连续两次成功且名称精确匹配作为额外保险，替换首次 Unix socket `pg_isready` 即通过逻辑；名称错配立即失败，查询非零重置连续成功计数。
|
||||
- [x] 增加 target query 退出码、名称匹配、尝试次数和连续成功次数的 allowlist 诊断，区分查询非零与名称错配；私有原始日志、失败先诊断后清理和零残留边界不变。
|
||||
- [x] 可复跑合同直接提取并驱动 rendered runner 中同一稳定就绪函数；fixture 外围与 runner 不同源的等待循环已删除。
|
||||
- [x] “socket 可用但 TCP 不可用仍失败”、首次失败后恢复、streak 重置、名称错配立即失败、永久查询失败有界退出五类回归通过；真实 `restore-db.sh` Docker stdin/host-file、源/副本身份、dynamic migration、附件安全、敏感输出和清理合同继续通过。
|
||||
- [x] 已审计合同全部覆盖机制，未发现第二套自写等价恢复逻辑；完整 runner 的 migration/12 类表/附件编排仍只能由真实隔离恢复验证，已作为明确限制保留，不能由本地组件合同替代。
|
||||
- [x] `scripts/restore-db.sh` 相对生产构建字节未改；runner、成对备份/恢复、自动异机备份 74 项、task、Trellis、process、docs、敏感扫描和空白门禁均通过。
|
||||
- [ ] 本地修复阶段不连接 ARM、不生成或安装 Attempt 5 现场入口。提交后重新选择最新批次并执行只读探针、重新渲染候选和核对 SHA-256；实际恢复须再次单独批准。
|
||||
|
||||
## 验证命令类别
|
||||
|
||||
|
||||
@@ -400,3 +400,30 @@ Attempt 4 的 runner 产生过程已从个人 workspace 人工产物改为“跟
|
||||
Attempt 4 前后探针的最新构建短标识、run id 配对、产物完整性和 manifest 脱敏摘要前缀一致，后置探针仍在 24 小时内通过。由此正式归档的内容级零修改已取得现场只读补证；该结论仅覆盖正式归档，不替代恢复成功证明，也不回答最新备份是否可恢复。
|
||||
|
||||
腾讯云生产演练后 `/ready` 仍未独立补证。ARM 的 timer active、清理 PASS 和归档探针均不能推导生产在线状态；在取得 `/ready` 正常状态及 12 位构建前缀前，AC2 保持未满足，证据不得表述为生产前后均正常。
|
||||
|
||||
## Attempt 4 后生产只读补证与本地稳定就绪修复
|
||||
|
||||
日期：2026-08-25
|
||||
|
||||
执行方沿既有审计窄路径完成腾讯云生产演练后 `/ready` 只读核验：状态 `PASS`，12 位构建前缀 `7b86ffb3c9ef`，与演练前记录一致。地址和原始响应未写入本证据；该读取没有登录、写库、重启、切换或配置修改。至此 Attempt 4 的生产前后 `/ready` 均正常已补证，但不改变本轮 restore apply 未执行和最新备份可恢复性仍未知的结论。
|
||||
|
||||
用户随后批准的范围仅为本地 runner 修复与回归，不连接 ARM、不执行 Attempt 5。修复把 PostgreSQL 就绪从默认 Unix socket 的首次 `pg_isready` 改为容器内 TCP 回环 `127.0.0.1` 的真实 `SELECT current_database()`：initdb 临时服务器不监听 TCP，因此该判据结构性排除临时服务器；连续两次成功和最多 60 次有界重试只作为额外稳定保险。目标名称成功但不匹配立即失败，查询非零重置 streak；实际 `restore-db.sh` 仍走原路径且字节不改。
|
||||
|
||||
合同夹具与 runner 分叉审计结果：
|
||||
|
||||
| 覆盖对象 | 合同机制 | 是否存在等价逻辑分叉 |
|
||||
| --- | --- | --- |
|
||||
| 私有配置渲染与候选 SHA | 直接使用跟踪模板和合同内唯一渲染器 | 否 |
|
||||
| 正式源/临时副本身份 | 从 rendered runner 提取 `validate_batch` 同一实现 | 否 |
|
||||
| PostgreSQL 目标就绪 | 从 rendered runner 提取同一 TCP 目标确认函数；真实 PostgreSQL 16 fixture 也调用该函数 | 原分叉已消除 |
|
||||
| DB restore Docker stdin/host-file | 直接执行仓库 `scripts/restore-db.sh` | 否 |
|
||||
| 附件引用安全 | 直接执行跟踪附件校验器 | 否 |
|
||||
| 失败诊断与 finally 清理 | 从 rendered runner 提取初始化和 finalization 同一实现 | 否 |
|
||||
| migration 指纹 | 对 rendered 值、目录集合变化和禁止硬编码做静态/合成断言 | 无等价重写；真实恢复集合仍待远端演练 |
|
||||
| 12 类表、storage 与完整编排 | 本地只做组件合同，不执行含真实备份的完整 runner | 明确覆盖限制，不能推断远端成功 |
|
||||
|
||||
就绪回归全部 `PASS`：socket 路径假定可用但 TCP 永久失败仍在第 60 次失败；首次查询失败后连续两次成功在第 3 次通过；一次成功后失败会清零 streak 并在第 4 次通过；目标名不匹配第 1 次立即失败；永久查询非零以 `TARGET_QUERY_NONZERO` 失败。真实 PostgreSQL 16 fixture 使用 extracted rendered-runner 函数就绪后，`restore-db.sh` Docker stdin 与 host-file 两条路径均成功；dump-list、目标错配、apply 非零、诊断先于清理、敏感输出负例继续通过。本地测试容器残留 `0`。
|
||||
|
||||
完整复跑结果：runner 合同全部 `PASS`，既有成对备份/恢复演练 `PASS`，自动异机备份合同 `74/74 PASS`；task validate、Trellis governance、process baseline、默认/定向敏感扫描和 `git diff --check` 均通过。文档审计错误 `0`，仅保留既有未登记文件 warning；`scripts/restore-db.sh` 相对生产构建无字节漂移，测试容器和生成缓存残留均为 `0`。
|
||||
|
||||
本地合同通过只证明演练器修复与组件路径，不回答最新正式备份是否可恢复。下一步仍须先提交可追溯变更，再动态选择最新正式批次、执行只读身份探针并重新渲染候选；Attempt 5 实际恢复必须另行批准。
|
||||
|
||||
在新工单中引用
屏蔽一个用户