有状态服务安全恢复的关键是确保数据可用、服务可信赖、不引发二次故障：1. 重启策略需配合命名卷或绑定挂载及可靠文件系统；2. 用细粒度HEALTHCHECK替代进程存活判断；3. 配置带退避的on-failure重启策略；4. 通过depends_on+service_healthy或启动脚本控制依赖启动顺序。
有状态服务（如数据库、缓存、消息队列）不能简单靠“重启容器”恢复，必须兼顾数据一致性、进程状态和外部依赖。安全恢复的关键不是让容器更快起来，而是确保它起来时数据可用、服务可信赖、不会引发二次故障。
1. 重启策略本身不解决有状态问题，必须配合持久化设计
Docker 的 always 或 unless-stopped 策略只能保证容器进程被拉起，但对以下风险无能为力：
- 容器重启后挂载的数据卷未同步或处于中间状态（例如 PostgreSQL 正在写 WAL 时断电）
- 多个副本同时重启导致脑裂（如 Redis Sentinel 集群中主节点未正确选举）
- 应用启动依赖外部服务（如 MySQL 启动前，应用已尝试连接并失败退出）
所以第一步是：用 命名卷（named volume）或绑定挂载（bind mount）明确声明数据路径，并确保宿主机磁盘使用 ext4/xfs 等支持日志的文件系统，禁用 noatime + data=ordered 模式提升写入可靠性。
2. 用健康检查替代“进程存活”判断，防止假启动
有状态服务常出现“进程在跑，但实际不可用”的情况（比如 MySQL 进程存活，但无法响应 SELECT）。此时仅靠 restart 策略会反复拉起一个“僵尸服务”。应启用细粒度 HEALTHCHECK：
- MySQL 示例：
HEALTHCHECK --interval=15s --timeout=5s --retries=3 CMD mysqladmin ping -u root -p$$MYSQL_ROOT_PASSWORD -h 127.0.0.1 || exit 1 - PostgreSQL 示例：
HEALTHCHECK --interval=10s CMD pg_isready -U postgres -d mydb
健康检查失败后，Docker 会将容器标记为 unhealthy；若搭配 on-failure 策略，可避免无效重启——真正实现“只在确认健康时才对外提供服务”。
3. 控制重启节奏，避免雪崩式重试
对有状态服务，连续快速重启极易加剧资源争抢或触发存储层保护机制（如 Linux OOM killer 杀掉数据库进程）。推荐配置带退避的失败重启：
- 在
docker-compose.yml中使用完整 restart_policy（需 Docker Engine ≥20.10）：
services:
postgres:
image: postgres:15
restart: "on-failure"
deploy:
restart_policy:
condition: on-failure
delay: 30s
max_attempts: 3
window: 120s
这段配置表示：仅当 PostgreSQL 以非零退出码终止时尝试重启，每次间隔 30 秒，2 分钟窗口内最多重试 3 次——给存储层和 WAL 恢复留出时间。
4. 宿主机重启后的安全启动顺序必须可控
服务器异常断电后，Docker 默认按容器创建时间顺序启动，但有状态服务依赖链（如 etcd → consul → app）必须严格有序。解决方案有两个：
- 用 Docker Compose v2.23+ 的 depends_on + condition: service_healthy，强制等待依赖服务健康后再启动本服务
-
在容器启动脚本中加入主动探测逻辑，例如应用启动前执行：
until nc -z database 5432; do sleep 2; done，避免因依赖未就绪而直接失败退出
注意：depends_on 本身不检查健康状态，必须显式加上 condition: service_healthy 才真正可靠。
