首选overlay2驱动（linux 4.0+内核），因其最稳定且元数据管理严谨；须禁用aufs和devicemapper，后者存在thin-pool空间回收延迟风险；需验证d_type=true、挂载启用barrier/sync、数据库配置同步刷盘、停机设置足够grace period并手动先关闭db。
保障容器内数据强一致性，不能只靠存储驱动本身，而要把它作为底层支撑，配合数据库行为控制、挂载策略和关机流程共同实现。存储驱动解决的是“文件怎么存、层怎么叠”的问题，但数据是否真正落盘、事务是否完整提交，得由上层应用和操作协同完成。
选对驱动并确认基础可靠性
首选 overlay2（Linux 4.0+ 内核），它是当前生产环境最稳定、元数据管理最严谨的驱动。避免使用已弃用的 aufs 或配置复杂的 devicemapper——后者在 thin-pool 空间回收上存在不可预测延迟，可能卡住 WAL 日志刷盘。
- 运行
docker info | grep "Storage Driver"确认输出为overlay2 - 检查底层文件系统是否启用
d_type=true：
— xfs：执行xfs_info /var/lib/docker | grep ftype，需返回ftype=1
— ext4：执行tune2fs -l /dev/xxx | grep "Filesystem features" | grep -E "(dir_index|filetype)"，两项都应存在 - 若未启用，不建议在线修复；生产环境应规划阶段重格式化或迁移至 xfs
卷挂载必须满足数据安全前提
绑定挂载（Bind Mount）或 Volume 都只是通道，关键在挂载选项是否禁用缓存、确保同步写入。
- 挂载时显式加
barrier=1（ext4）或sync（xfs），防止掉电丢日志 - 禁止使用
:z或:ZSELinux 标签挂载数据库数据目录，策略延迟可能导致fsync失败 - PostgreSQL/MySQL 数据目录必须挂载为 独立 Volume，不要混用匿名卷或临时目录
- 示例（Compose 中）：
volumes:- db-data:/var/lib/postgresql/data...volumes:db-data:driver: local
停机过程必须绕过默认 docker stop
Docker 默认 stop 只等 10 秒就发 SIGKILL，而数据库关机需完成 checkpoint、WAL 刷盘、缓冲区同步——通常耗时 20–60 秒。
- 在
docker-compose.yml中设：stop_grace_period: 60sstop_signal: SIGTERM（PostgreSQL 默认响应，MySQL 也支持） - 计划性维护时，**先手动关闭数据库**：
— PostgreSQL：docker exec db pg_ctl stop -m fast
— MySQL：docker exec db mysqladmin shutdown -u root -p$PASS - 确认进程退出后再
docker stop，此时仅清理网络与挂载点，无数据风险
数据库自身配置是最后一道防线
存储驱动和挂载再可靠，也替代不了数据库层的持久化语义保证。
- PostgreSQL：
—wal_level = replica
—synchronous_commit = on
—fsync = on - MySQL：
—innodb_flush_log_at_trx_commit = 1
—sync_binlog = 1
—innodb_doublewrite = ON - 验证方法：关机后检查日志末尾是否有
database system is shut down（PG）或mysqld: Shutdown complete（MySQL）
不复杂但容易忽略：强一致性不是某个开关，而是从内核文件系统、Docker 存储驱动、挂载参数、数据库配置到运维动作的一整条链路闭环。
