数据库容器停用时需避免默认 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/:Z SELinux 标签挂载数据库目录，防止策略延迟导致 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）做元数据一致性快照比对