orbit/docs/reports/phase-6-db-recovery.md

P6：MySQL 短暂不可用恢复基线

验证日期：2026-09-20。本批针对生产验收项 A18，验证 Orbit 在 MySQL 容器短暂停止并以同一数据卷恢复后，readiness 和任务受理行为保持可核对。

实际环境与命令

环境为 macOS arm64、Docker Go 1.27.1 交叉构建的当前 Orbit 二进制、Docker MySQL 8.4。脚本创建随机本地卷和端口，迁移 28 个版本，初始化一个通用命名空间和队列：

@@BT@sh ORBIT_BIN=/tmp/orbit-go127-darwin/orbit ORBIT_MIGRATE_BIN=/tmp/orbit-go127-darwin/orbit-migrate ORBIT_ADMIN_BIN=/tmp/orbit-go127-darwin/orbit-admin \ ORBIT_TEST_MYSQL_IMAGE=mysql:8.4 sh scripts/test-db-recovery.sh @@BT@

数据库容器停止并移除后，脚本在相同端口和卷上创建恢复容器；Orbit 进程保持运行。

实际结果

@@BT@json {"initial_readiness":200,"during_database_outage":503,"after_database_recovery":200,"task_accepted_after_recovery":true} @@BT@

恢复后的任务受理使用原命名空间凭据和固定 Idempotency-Key，说明新数据库连接能重新通过鉴权、结构检查、权限和受理事务。脚本没有启动 Worker，因此没有把任务受理误报为业务处理完成。

Go 1.27.1 交叉构建、脚本语法检查和文档链接检查通过；实际数据库结构继续由 orbit-admin verify 核对零外键。标准全量回归仍需在资源充足环境执行，不能用本次短暂中断演练替代。

边界

本证据只覆盖单节点数据库连接中断和同卷恢复。它不证明 MySQL 主节点切换、复制确认、跨故障域、磁盘损坏、备份介质持久性、进行中租约接管、外部副作用核对、生产容量或 RPO/RTO。生产上线仍需按目标拓扑独立演练。