# 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 都会拒绝实际外键漂移。