orbit/docs/api/db-recovery.md

MySQL 短暂不可用恢复演练

Orbit 不在运行时自动执行迁移，也不把数据库错误伪装成业务成功。GET /health/ready 每次都在有限上下文内执行数据库 Ping、迁移账本和零外键检查；数据库不可用时返回 503，恢复后由 database/sql 连接池重新建立连接。

可复现命令

@@BT@sh DOCKER=/usr/local/bin/docker \ ORBIT_TEST_MYSQL_IMAGE=mysql:8.4 \ sh scripts/test-db-recovery.sh @@BT@

脚本会创建一次性 MySQL 容器和本地卷，迁移当前结构，初始化通用应用/命名空间/队列，启动 Orbit；然后停止并移除数据库容器，在相同主机端口和卷上创建恢复容器。恢复后会再次请求 readiness，并提交一条原权限范围内的任务。临时凭据、容器和卷均由脚本清理。

成功输出：

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

运行边界

• 503 只表示当前节点不能确认数据库和结构，不代表任务已回滚或外部效果已撤销；写请求超时仍必须保留原幂等键核对。
• 数据库恢复后只证明新连接可以读取迁移账本并继续受理，不证明正在执行的任务、租约、复制确认或外部副作用已经自动完成。
• 该演练使用本地 MySQL 卷模拟单节点短暂中断，不等同于主从切换、复制延迟、跨故障域、磁盘故障、RPO/RTO 或生产容量验收。
• 数据库保持无外键；orbit-admin verify 和 readiness 都会拒绝实际外键漂移。