上周有个朋友半夜找我说他服务器重启后跑在 Docker 里的 MySQL 数据全没了。我第一反应是问他当时怎么启动的容器结果发现他直接用了docker run -d mysql:8.0这类最基础的写法数据库文件全写在了容器可写层里。容器一删或宿主机一重启状态说没就没。这不是个例我在社区里见过太多人把容器当虚拟机用结果数据丢了、性能拉了、磁盘满了最后排查下来问题几乎都出在存储这一层Docker 存储驱动没选对、数据卷没挂好、持久化没落到卷上、IO 路径拉得太长。这篇东西我不会给你念官方文档而是把存储驱动和数据卷这两块掰开揉碎讲一遍先讲清楚容器为什么“留不住数据”再讲存储驱动对读写性能的影响然后带你从一条docker run命令到 docker compose 完整落地数据卷最后把 MySQL、Redis 这类常见应用的持久化与性能优化实操方案直接列出来。适合刚把 MySQL/Redis 装进容器的新手也适合已经跑了一段时间、但时不时遇到“数据丢、写入慢、磁盘爆”的老手。1. 先弄清痛点在哪儿容器可写层为什么留不住数据很多人在第一次接触 Docker 时会下意识把容器当成一台轻量虚拟机在虚拟机里装 MySQL数据写在虚拟磁盘里关机重启数据还在。但容器不是这样工作的。Docker 容器的文件系统由镜像层和可写层构成理解这个基本盘后面所有关于持久化和性能的事才讲得通。1.1 镜像分层与写时复制的基本盘一个 Docker 镜像是一堆只读层叠加出来的每一层对应 Dockerfile 里的一条 COPY、RUN 等指令。比如你拉一个 mysql:8.0它内部可能叠了几十层每一层都记录着文件系统的一部分变更。容器运行时Docker 在镜像层之上再挂一个可写层所有对文件的修改都先落到这个可写层里。这个机制叫“写时复制”Copy-on-WriteCOW。读一个文件时Docker 会从上往下逐层查找改一个文件时如果目标文件在下面的只读层需要先把它复制到可写层再修改。问题就出在这容器运行期间产生的所有数据数据库的 binlog、redo logRedis 的快照业务日志全都堆在这个薄薄的可写层里。容器一旦被docker rm删除可写层连同里面所有数据一并销毁。这就是“容器留不住数据”的根本原因。有人会问那我容器不删数据是不是就安全了也不是。宿主机崩溃、磁盘故障、或者你执行了docker system prune之类的清理操作可写层都很脆弱。更重要的是可写层从来不应该是业务数据的归宿它只是运行时临时状态的家。1.2 数据落在可写层的三个典型后果把数据库这类强持久化应用直接跑在可写层上通常会遇到三个问题我基本上在排障时都见过第一是数据丢失。容器重建、宿主机重启、误删容器操作系统的状态全部归零。很多新手中的新手会在“容器删了数据还在吗”这个问题上栽跟头答案很残酷默认情况下删容器等于删数据。第二是性能不稳定。可写层的数据最终也要落到宿主机磁盘上但因为有了写时复制这一层逻辑频繁修改大文件时会有额外的复制开销。实测在容器可写层里跑 MySQL和小数据量时看不出差距数据一多、写入一频繁fsync 延迟明显升高整体写入吞吐掉一截。第三是磁盘空间失控。可写层里积累的日志、临时文件、数据库碎片在docker system df里看到的就是“可写层”那块占用而且很难单独清理。你删了容器这些空间不一定会立刻释放残留的 build cache 和悬空层会越堆越多。所以结论很简单凡是要长期保留的数据一律放到数据卷volume或绑定挂载bind mount里而不是写进容器可写层。这个原则没有例外。2. Docker 存储驱动选型为什么多数场景默认 overlay2 就够了存储驱动是 Docker 用来管理镜像层和容器可写层之间映射关系的底层引擎。不同驱动背后的文件系统机制不一样直接影响读写性能。这也是标题里“存储驱动”这部分要解决的核心问题。2.1 overlay2 的工作流程与性能关键点现代 Linux 环境下Docker 默认使用 overlay2它基于内核的 OverlayFS 实现把镜像层作为 lowerdir、容器可写层作为 upperdir挂载出一个 merged 目录给容器看到完整文件系统。这个设计让镜像层可以在多个容器之间共享同样的基础镜像十个容器共用一份只读层内存和磁盘都省。写文件时OverlayFS 做 copy-up把底层文件复制到可写层再修改。对数据库这类有小量随机写、大量 fsync 的工作负载copy-up 只在文件第一次被修改时发生真正频繁的写入还是直接落在 upperdir 对应的宿主机目录里所以 overlay2 的额外开销其实有限。但如果底层文件系统不支持 d_type目录项文件类型overlay2 会退化成索引模式读取目录和元数据时性能会明显打折。检查方法很简单docker info | grep -A5 Storage Driver如果看到Backing Filesystem: ext4或xfs通常没问题如果是网络文件系统或某些老式文件系统就要留个心眼。我自己在 xfs 格式的老 CentOS 上遇到过 overlay2 跑得慢的情况后来确认是 d_type 支持有问题换成 ext4 后写入延迟立刻恢复正常。2.2 不同存储驱动怎么选一张表讲清楚不是所有环境都适合 overlay2。早期 Docker 用过 aufs、devicemapper后来在特定文件系统上还支持 zfs、btrfs 等。它们各有适用场景但也各有代价。存储驱动底层依赖优点典型问题适用场景overlay2ext4/xfs支持 d_type默认驱动社区验证充分镜像共享好依赖内核版本老内核上性能打折绝大多数生产环境aufs需要内核支持 aufs老牌驱动早期历史长未进入主线内核新发行版基本没了不推荐过度方案devicemapper需要配置 thin pool曾经是 RHEL 默认配置复杂loop-lvm 模式性能极差应避免历史包袱btrfs/zfs对应文件系统自带快照、压缩能力和 Docker 层共用文件系统特性资源占用偏高特殊存储方案比如需要文件级快照时从我接触过的团队看绝大多数项目都用不着换驱动先把 overlay2 调好、把数据卷挂对性能问题就解决一大半了。那些一上来就折腾 zfs、btrfs 的反而常常在运维层面给自己挖坑。2.3 判断当前环境存储类型的两个命令你不需要背驱动特性但至少要知道当前环境用的是啥、底层文件系统是啥排障时心里有数。docker info重点看 Storage Driver、Backing Filesystem、Docker Root Dir 这三行。我每次接手一台陌生的服务器都会先跑这个命令几秒钟就能判断后面调优方向。另外一个常见问题是在 Docker Desktop 这种跑在虚拟机里的环境中底层文件系统是虚拟机里的虚拟磁盘格式宿主机和容器之间的文件路径可能不是你以为的那个。3. 数据卷、绑定挂载和 tmpfs三种持久化方式怎么选数据要持久化就绕不开挂载mount。Docker 里常见的有三条路绑定挂载bind mount、数据卷volume、tmpfs 挂载。三者性格完全不同选错了不是丢数据就是权限噩梦。3.1 三种挂载方式的核心差异对比维度bind mountvolume数据卷tmpfs mount数据位置宿主机任意目录Docker 管理的 /var/lib/docker/volumes/ 下容器内存由谁管理宿主机管理员Docker daemonDocker daemon宿主机共用是路径清晰不推荐直接改目录内容否容器删除后数据保留默认保留除非用 --rm 且无卷消失主要场景开发热加载、日志收集数据库数据、配置文件、跨容器共享临时缓存、敏感凭据bind mount 最直观比如开发时把宿主机项目目录挂进容器改代码即时生效不用重新构建镜像。但它的权限边界模糊宿主机目录的 uid/gid 直接暴露给容器容器里进程如果以 root 跑等于给了宿主机目录相当大的写入能力这在生产环境里要想清楚。volume 是官方推荐的首选。它由 Docker 统一管理放在 Docker Root Dir 下的 volumes 子目录里跨机器迁移、备份都很方便。更关键的是官方镜像里用VOLUME指令声明的目录默认就是给你挂数据卷准备的比如 mysql 的/var/lib/mysql、redis 的/data。你只要挂上卷容器删掉再重建数据还在。tmpfs 挂载则完全是内存盘写入速度极快但重启即失。适合放临时文件、session、敏感令牌这类“不落地”的数据。我一般给临时计算任务用而不是存业务数据。3.2 命名卷在宿主机上的真实目录结构在 Linux 上创建一个命名卷后它的数据会落在/var/lib/docker/volumes/卷名/_data。比如docker volume create mysql-data docker inspect mysql-data你会看到它的 Mountpoint 指向/var/lib/docker/volumes/mysql-data/_data。这地方需要注意它本质是宿主机上的普通目录但你不应该直接用宿主机路径去读写卷里的文件尤其是数据库类卷。我见过有人把/var/lib/docker/volumes/mysql-data/_data里的数据拷出来恢复操作没错但一旦 Docker 使用的文件系统锁和缓存机制介入直接改文件容易导致数据不一致。正确做法是用临时容器做备份和恢复后面讲。3.3 容器间共享与权限踩坑有的场景需要多个容器访问同一份数据比如 Nginx 和 PHP-FPM 共用静态文件目录或者日志采集容器读业务容器的日志文件。bind mount 最简单宿主机上一个目录挂给两个容器就行volume 也能做到把同一个命名卷挂给多个容器。但权限问题是重灾区。bind mount 宿主机的目录如果归属 root容器内进程以 www-data 用户运行时可能没有写权限。MySQL 镜像更麻烦官方 mysql 镜像首次初始化数据目录时必须保证目录归属 mysql 用户如果 bind 挂载的宿主机目录归属不对初始化直接失败。我常用的技巧是先创建一个空目录然后临时用--user参数跑一个只做 chown 的容器修正归属再正式启动数据库容器。chown -R 999:999 /data/mysql操作前务必确认镜像里 mysql 用户的 uid/gidMySQL 官方镜像通常是 999不同版本可能不一样以docker exec 容器名 id mysql的实际输出为准。4. 数据卷实操从一条命令到 compose 全面接管理解了原理接下来就是直接能抄的实操。我不会故作高深下面这些都是我自己在项目里用过的写法。4.1 创建卷与挂载的基础命令先创建一个命名卷docker volume create mysql-data启动容器时挂载两种写法等价建议优先用--mount可读性更好docker run -d \ --name mysql8 \ -v mysql-data:/var/lib/mysql \ -e MYSQL_ROOT_PASSWORDyourpass \ mysql:8.0或者docker run -d \ --name mysql8 \ --mount typevolume,sourcemysql-data,target/var/lib/mysql \ -e MYSQL_ROOT_PASSWORDyourpass \ mysql:8.0绑定挂载也经常用比如把宿主机配置目录挂给容器docker run -d \ --name nginx \ -v /etc/nginx:/etc/nginx:ro \ -v /www/html:/usr/share/nginx/html \ nginx:1.25:ro表示只读防止容器内进程误改宿主机配置。这条建议养成习惯能用只读就用只读少一类安全隐患。4.2 docker compose 中声明数据卷的标准写法现在跑应用我基本都用 compose 管。compose 里定义卷非常清晰服务里用volumes列出挂载关系文件底部用顶层volumes声明卷名services: mysql: image: mysql:8.0 container_name: mysql8 restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD} MYSQL_DATABASE: appdb volumes: - mysql-data:/var/lib/mysql - ./mysql/conf.d:/etc/mysql/conf.d:ro ports: - 3306:3306 volumes: mysql-data:docker compose up -d后compose 会自动创建名为项目名_mysql-data的卷。这里有个坑如果你之前在单独docker run里手动创建过mysql-datacompose 因为命名空间规则不会自动复用会另外建一个卷导致“数据好像不见了”。解决办法是给卷指定名称volumes: mysql-data: name: mysql-data这样 compose 就会直接使用已存在的命名卷数据不会丢。这是我在迁移老容器到 compose 时踩过的实坑。常用项目里Kodbox网盘、青龙定时任务、GitLab 这类应用都需要挂多个卷。以 Kodbox 为例数据目录、配置目录、临时目录分别挂载services: kodbox: image: kodbox/kodbox:latest volumes: - kodbox-data:/var/www/html - kodbox-config:/etc/nginx/conf.d ports: - 8080:80 volumes: kodbox-data: kodbox-config:4.3 卷的备份、恢复与迁移卷数据不能直接拷贝宿主机目录至少不该作为首选。我当然知道很多人会直接 tar/var/lib/docker/volumes/mysql-data/_data速度快但我碰到过一次因为容器还在写数据、直接 tar 出来的备份不一致的情况所以现在都用临时容器做一致性备份。备份一个命名卷最稳妥的写法docker run --rm \ -v mysql-data:/data \ -v /backup:/backup \ alpine tar czf /backup/mysql-data.tar.gz -C /data .恢复时也是一样的思路先把 tar 解压回卷数据目录docker run --rm \ -v mysql-data:/data \ -v /backup:/backup \ alpine tar xzf /backup/mysql-data.tar.gz -C /data注意恢复前一定要先停掉正在用这个卷的容器否则数据目录被占用、文件锁冲突解压完你都不知道哪些文件是新的哪些是旧的。迁移到另一台机器时把 tar 包拷过去再执行同样的恢复命令就行卷的名字建议保持一致避免配置改动。5. 性能优化实战让 MySQL 和 Redis 在容器里跑得又快又稳说到性能优化很多人第一反应是调容器 CPU/memory 限制但我实测下来存储层面的优化往往收益更大。数据路径一乱配置再好也白搭。5.1 耗时瓶颈通常不在存储驱动而在数据路径一个常常被忽略的事实绑定挂载和命名卷本质上都是直接访问宿主机目录并不经过 overlay2 的可写层。也就是说真正影响性能的不是存储驱动本身而是你把数据放在了哪条路径上。容器内写文件有三个可能去处一是 overlay2 可写层写入可能触发 copy-up大文件频繁修改时延迟明显二是 volume直接落到宿主机文件系统性能和裸机目录非常接近三是 tmpfs写内存最快。数据库这个级别的写入永远应该走第二条路。我做过一次不算严谨的对比同样跑 MySQL 的 sysbench 写测试小表数据量下容器可写层和 volume 的差距在 10% 以内但数据量涨到 10GB、同步刷盘开启时可写层的延迟明显增大偶尔出现明显抖动。这其实是 copy-up 和碎片化在叠加。结论就是数据库数据目录必须用 volume别让写时复制耽误你。5.2 MySQL 容器写盘性能优化实录一个完整可靠的 MySQL 容器至少要做到三件事数据卷挂载、二进制日志限流、日志驱动收敛。首先启动 MySQL 时挂载数据卷docker run -d \ --name mysql8 \ --mount typevolume,sourcemysql-data,target/var/lib/mysql \ -e MYSQL_ROOT_PASSWORDyourpass \ mysql:8.0其次是 MySQL 自身的刷盘策略。默认配置下innodb_flush_log_at_trx_commit1每次事务提交都强制刷盘安全但慢。如果你能接受极端情况丢 1 秒事务改成2性能提升非常明显。比如在配置文件中添加[mysqld] innodb_flush_log_at_trx_commit 2 innodb_buffer_pool_size 2G这两个参数在容器里同样生效前提是你把配置文件挂进去了。例子docker run -d \ --name mysql8 \ --mount typevolume,sourcemysql-data,target/var/lib/mysql \ --mount typebind,source/etc/mysql/conf.d,target/etc/mysql/conf.d,ro \ mysql:8.0然后是日志驱动。Docker 默认 json-file 日志驱动如果没限制大小MySQL 的错误日志、慢查询日志会滚成巨无霸既拖累宿主机 IO也占磁盘。启动容器时加日志参数docker run -d \ --name mysql8 \ --log-driverlocal \ --log-opt max-size10m \ --log-opt max-file3 \ mysql:8.0local驱动本身是给 Docker 内部日志用的格式紧凑性能比 json-file 好配合滚动策略日志再也不会无限膨胀。生产环境里这是我最常用的组合。5.3 Redis 持久化机制与卷配合Redis 的持久化常见有 RDB、AOF 两种机制。RDB 是定时快照恢复快但可能丢数据AOF 记录每一条写命令数据安全但文件大。现在主流是混合持久化AOF 重写时生成 RDB 格式的基线再叠加增量命令。无论哪种数据文件都默认落在/data目录官方镜像也把/data暴露成 VOLUME。所以你只需要挂一个卷docker run -d \ --name redis7 \ --mount typevolume,sourceredis-data,target/data \ redis:7-alpine --appendonly yes启动参数里--appendonly yes开启 AOFappendfsync everysec每秒刷盘一次这是性能和安全的常见平衡点。如果要更稳可以设always但写入延迟会明显上升我一般只在库存、交易类场景里用。Redis 的 AOF rewrite 会频繁产生临时文件一旦卷所在磁盘空间不足rewrite 失败还可能触发 Redis 停止写入。所以挂卷之后要留出至少一倍数据集大小的余量或者定时清理rdb/aof历史文件。5.4 容器日志与宿主机层面的隐藏开销容器运行时还有一类常被忽略的 IO 消耗Docker 日志驱动。默认 json-file 驱动不仅膨胀快写入也是串行的日志量大的容器会拉高整体 CPU 和 IO 压力。我从去年开始把大多数容器的日志默认切到local驱动或者至少限制 max-size 和 max-file实测对高并发写入场景帮助明显。宿主机层面如果跑的是数据库容器务必保证/var/lib/docker挂载在 SSD 上而不是机械盘或网络盘。有人问我跑 20 个容器为什么磁盘 IO 那么高我一看Docker Root 落在了一个旧 NAS 上那就算存储驱动调出花来底层的随机写性能也救不回来。这一步比任何调参都实在。6. 常见问题与排查技巧实录最后这部分我把日常被问得最多的问题集中列一下很多都是热词里反复出现的“老朋友”docker 权限错误、virtualisation support 检测不到、镜像下载慢、docker 网络不通、磁盘占满。6.1 启动失败与权限报错如果你在 Linux 上用非 root 用户执行 docker 命令报permission denied while trying to connect to the Docker daemon socket大概率是用户不在 docker 组。解决办法sudo usermod -aG docker $USER newgrp docker然后重新登录终端。重试前记得确认 docker 守护进程在运行systemctl status dockerWindows/macOS 上 Docker Desktop 启动时报virtualisation support wasnt detected这类错误通常是虚拟化没开或 WSL2 没启用。先去 BIOS 把 Intel VT-x / AMD-V 打开再检查“启用 Windows 虚拟机监控程序平台”和“适用于 Linux 的 Windows 子系统”这两个功能是否勾选。这个问题在 Windows 11 上尤其常见装完 Docker Desktop 起不来十有八九是虚拟化相关功能没开全。6.2 镜像下载慢与网络不通的处理镜像拉取慢是几乎所有新手都会碰到的事。我推荐的方法很朴素的优先使用可信的公共容器镜像服务或配置 registry-mirror 镜像加速。给镜像打上明确 tag不要只用 latest减少无谓的层下载。内网环境就用 registry 私有仓库把常用镜像 upload 到内网再分发。Docker 网络不通的问题典型现象是容器访问不了外网或者容器之间互相 ping 不通。排查顺序是先看容器网络模式docker network ls docker inspect 容器名 | grep -A20 Networks默认 bridge 网络下容器通过 NAT 访问外网如果你手动--network host或自定义 network要确认宿主机的防火墙规则和 IP 转发是否开启。容器间互通用自定义 bridge 网络比如docker network create app-net然后把相关容器都加入这个网络用服务名或容器名互相访问比我以前用--link灵活多了。6.3 磁盘占满与孤儿卷清理跑一段时间后磁盘被 Docker 掏空绝对算是高频事故。先看占用docker system df这个命令会列出镜像、容器、本地卷、构建缓存各占多少。清理时按需操作# 清理悬空镜像、停止的容器、无用网络 docker system prune # 连构建缓存一起清 docker system prune -a # 清理无主数据卷 docker volume prune特别说一句docker system prune默认不会删数据卷因为卷里的可能是你的宝贝数据。但如果你明确知道哪些卷没用了docker volume prune一次清掉最省事。身边很多人在“容器删了但空间没释放”问题上抓狂多半是没意识到构建缓存和旧镜像还在占地方先把docker system df这个体检技能用起来问题就能看明白一大半。6.4 数据卷删不掉与误删预防试图删除一个还被容器使用的卷时Docker 会直接拒绝并提示卷正在被使用。这其实是保护机制但反过来也带来一个困扰你不会总是记得哪个卷还被哪个容器占用。这时用docker ps -a --filter volume卷名查出占用容器。如果容器已经不在而卷还挂着文件docker volume prune也只删无主卷确认没错再手动删docker volume rm 卷名误删预防这块我养成了一个习惯所有带有明显业务属性的卷都用命名卷并用项目名做前缀例如app-mysql-data、app-redis-data。匿名卷很难追溯一旦容器被删匿名卷虽然还在宿主机上但你很难知道它是谁的。给卷起好名字也算是一种成本极低的运维规范。另外一个建议是生产环境执行任何 prune 之前先做一次卷备份哪怕只是几分钟前打好的 tar 包也比事后找人恢复强。我见过太多半夜三点找人拉数据恢复的场面几乎所有情况都源于“我以为没影响”和“我以为备份了”。我自己在实际操作里的体会是Docker 存储这块不需要什么花活存储驱动默认 overlay2 别乱换数据卷老老实实挂上日志限流开好备份演练做一次。这些做好之后你才会真正觉得容器是可靠的运行环境而不是一个随时会丢数据的高级玩具。如果你正打算把 MySQL、Redis 这类应用迁到 Docker或者已经被丢数据、慢写入折磨过不妨按这篇文章重新梳理一遍你的卷和存储路径能少走太多弯路。