数据库服务推荐使用unless-stopped策略，因其支持异常退出和宿主机重启后的自动恢复，且人工停止后不重启，符合运维可控性；须配合内存限制、健康检查（如pg_isready）及持久化存储，避免盲目重启掩盖数据一致性问题。
docker 容器重启策略本身不能修复数据库崩溃的根本原因，但它能为数据库服务提供基础的“自动拉起”能力，防止一次异常退出导致长时间不可用。关键在于选对策略、配好资源限制和健康检查，避免盲目重启掩盖问题。
数据库服务推荐用 unless-stopped 策略
这个策略最适配长期运行的数据库容器（如 PostgreSQL、MySQL）：
- 容器因 OOM、主进程崩溃、磁盘满等异常退出后，会自动重启；
- 宿主机重启后，Docker 守护进程启动时也会自动拉起该容器；
- 唯一不重启的情况是人工执行
docker stop—— 这符合运维可控性要求。
示例命令：
docker run -d \ --name my-postgres \ --restart unless-stopped \ -e POSTGRES_PASSWORD=123 \ -v /data/pg:/var/lib/postgresql/data \ -p 5432:5432 \ postgres:15
必须配合资源限制，防止反复 OOM 崩溃
数据库对内存敏感，若不限制，容易被 Linux OOM Killer 杀掉（退出码 137），然后无限重启——这不是恢复，是恶性循环。
在 docker run 中加：
--memory=2g --memory-swap=2g --oom-kill-disable=false
或在 docker-compose.yml 中：
deploy:
resources:
limits:
memory: 2G
cpus: '1.0'
加上健康检查，让重启更“有判断”
单纯靠进程退出码重启不够智能。数据库可能进程还在，但连接池卡死、主从断开、wal 归档失败——这些不会触发 on-failure。
推荐在 docker-compose.yml 中配置：
healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres -d mydb || exit 1"] interval: 30s timeout: 10s retries: 3 start_period: 60s
这样 Docker 会主动探测数据库是否真正可服务，连续失败 3 次才标记 unhealthy，再结合 restart: unless-stopped 触发重启。
注意：重启不是万能，数据一致性优先
- 如果数据库因写入中断导致数据卷损坏，重启只会让损坏状态持续；
- 务必把数据目录挂载到宿主机（如
-v /data/pg:/var/lib/postgresql/data），并定期备份； - 避免使用
always策略：它会在你手动docker stop后仍强行重启，干扰维护操作。
本质上，重启策略是兜底手段，不是替代监控与修复。真正可靠的数据库服务，需要：资源限制 + 持久化存储 + 健康检查 + 备份机制 + 日志分析闭环。
