Docker stop 默认行为无法保障数据库数据一致性，因其仅等待10秒即发SIGKILL，而PostgreSQL/MySQL关机需完成WAL刷盘、缓冲区同步等操作，耗时远超10秒；应配置stop_grace_period≥60s、使用pg_ctl stop或mysqladmin shutdown主动关闭、结合synchronous_commit=on等存储层防护，并通过日志和启动后校验确认安全关闭。
不能靠
默认行为保障数据库数据一致性。它默认只等 10 秒就发 sigkill，而 postgresql 或 mysql 在关闭时需完成 wal 刷盘、缓冲区同步、事务提交等操作，时间远超 10 秒。真正安全的做法是让数据库进程主动响应 sigterm 并完成清理，再由
docker
收尾容器运行时环境。
显式配置停止信号与超时时间
Docker 的
和
必须按数据库实际关机耗时设定：
PostgreSQL 默认监听 SIGTERM，无需改
；MySQL 同理，但需确认 mysqld 启动参数未禁用信号处理
建议设为 60s 起：例如 Compose 中写
，给 checkpoint、flush buffer pool、sync WAL 留出足够窗口
避免在健康检查中设置过激的失败阈值，防止停机过程中因探针失败触发自动重启，干扰正常关机流程
计划停机必须绕过 Docker 生命周期
对数据库容器执行计划性维护（如升级、迁移）时，
不应直接 docker stop
。应先在容器内调用数据库原生命令完成固化：
PostgreSQL：
（推荐），确保所有活跃事务结束、WAL 完全刷盘
MySQL：
，比 kill 或 docker kill 更可靠
确认容器内数据库进程已退出（
无主进程），再执行
—— 此时只是清理网络命名空间和挂载点，无数据风险
结合数据库与存储层做纵深防护
Docker 本身不解决断电问题，需叠加数据库配置与底层存储能力：
Docker Sandbox
创建并管理 Docker 沙箱虚拟机环境以安全执行代理。适用于运行不受信任代码、探索包或隔离代理工作负载。支持 Claude、Codex、Copilot、Gemini 和 Kiro 代理，并提供网络代理控制。
下载
PostgreSQL 开启强一致性：设置
+
MySQL 启用双刷：
+
挂载卷使用 ext4/xfs 并启用
；确保存储设备支持 PLP（如带电容的 NVMe 或 RAID 卡），防止掉电丢日志
禁止用
或
SELinux 标签挂载数据目录，避免策略延迟导致 sync 失败
验证是否真正安全关闭
仅看容器退出码或状态为
不代表数据安全。必须检查：
容器日志末尾是否有明确 shutdown 标记：PostgreSQL 显示
，MySQL 显示
下次启动后观察错误日志：若出现
、
或
，说明上次关闭不完整
必要时做逻辑校验：比如对比关键表行数、检查主从 GTID/LSN 是否连续
docker stopstop_signalstop_grace_periodstop_signalstop_grace_periodstop_grace_period: 60sdocker exec -it db pg_ctl stop -m fastdocker exec -it db mysqladmin shutdown -u root -p$PASSdocker exec db ps aux | grep postgresdocker stopwal_level = replicasynchronous_commit = oninnodb_flush_log_at_trx_commit = 1sync_binlog = 1barrier=1:z:ZExited (0)database system is shut downmysqld: Shutdown completecrash recoverypage checksum mismatchInnoDB: Database page corruption