数据库容器停用时需避免默认 docker stop 导致数据损坏，应配置 stop_signal、延长 stop_timeout、禁用干扰健康检查，并结合数据库日志同步、文件系统 barrier、PLP 等实现纵深防护；计划停机须先执行 pg_ctl stop 或 mysqladmin shutdown，再 docker stop；并通过日志、错误提示及一致性校验验证安全关闭。
数据库容器在 Docker 中停用时，不能依赖默认的 docker stop 行为实现数据安全落盘。Docker 的 SIGTERM + 等待超时（默认 10 秒）+ SIGKILL 强杀机制，对数据库类有状态服务存在风险：事务未提交、WAL 未刷盘、缓冲区未同步，可能导致数据损坏或恢复失败。
确保数据库容器优雅关闭的关键配置
核心是让容器内数据库进程能响应 SIGTERM 并完成清理，而非被强制终止：
-
显式指定停止信号：在
docker run或docker-compose.yml中设置stop_signal: SIGTERM（PostgreSQL/MySQL 默认已监听该信号，无需改） -
延长停止超时时间：使用
--stop-timeout（CLI）或stop_grace_period（Compose），例如设为60s，给数据库足够时间完成 checkpoint、flush buffer pool、sync WAL - 禁用非必要健康检查干扰：避免在停止过程中因健康探针失败触发误判或自动重启
宿主机断电级防护的补充手段
Docker 本身不解决物理断电问题，需结合底层与数据库自身能力构建纵深防护：
-
启用数据库持久化日志机制：如 PostgreSQL 的
wal_level = replica+synchronous_commit = on；MySQL 的innodb_flush_log_at_trx_commit = 1+sync_binlog = 1 -
挂载卷使用支持 barrier/direct I/O 的文件系统（如 ext4/xfs 启用
barrier=1），并确保存储设备开启写缓存保护（如带电池/电容的 RAID 卡或 NVMe 的 PLP 功能） -
避免使用
:z/:ZSELinux 标签挂载数据库目录，防止策略延迟导致 sync 失败
停机前的主动数据固化操作
在计划性维护或迁移前，应绕过 Docker 生命周期，直接进入容器执行数据库级安全停机：
- PostgreSQL：
docker exec -it db pg_ctl stop -m fast或-m smart（推荐fast，确保所有事务结束且 WAL 刷盘） - MySQL：
docker exec -it db mysqladmin shutdown -u root -p$PASS（避免用kill或docker kill） - 确认进程退出后再执行
docker stop，此时只是清理容器运行时上下文，无数据风险
监控与验证停机完整性
仅靠容器退出码无法判断数据库是否真正安全关闭：
- 检查容器日志末尾是否有数据库明确的 shutdown 成功标记，如 PostgreSQL 的
database system is shut down，MySQL 的mysqld: Shutdown complete - 启动后观察错误日志是否出现 crash recovery、page checksum mismatch、InnoDB force recovery 等异常提示
- 对关键业务库，在停机前后执行
pg_controldata（PG）或mysqlcheck --check（MySQL）做元数据一致性快照比对
