Docker 部署达梦 DM8 从零到一：40G 小硬盘的极限求生与踩坑实录

前言
最近在阿里云 40G 的 ECS 上用 Docker 部署达梦 DM8 数据库，本以为轻车熟路，结果一路踩坑：根目录被占满、表空间创建失败、容器日志撑爆磁盘、导入导出路径混乱……幸好最终全部解决。这篇文章记录了我从磁盘 100% 到顺利导入 dmp 备份的全过程，希望帮后来者避开这些“致命”细节。

一、环境概览

• 云服务器：阿里云 ECS（40G 系统盘）

• OS：CentOS 7

• 数据库：达梦 DM8（Docker 镜像 dm8:v1.0）

• 容器名：dm8，实例名：DMSERVER

• 目标：创建业务表空间、新建用户、导入业务数据（.dmp）

二、第一大坑：根目录 100% 怎么救？

1. 症状

执行任何建表空间命令都报 No space left on device

df -h 显示 / 可用为 0

[root@iZwz9i0ey3mo5h7inxu74uZ ~]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 916M 0 916M 0% /dev
tmpfs 936M 0 936M 0% /dev/shm
tmpfs 936M 800K 935M 1% /run
tmpfs 936M 0 936M 0% /sys/fs/cgroup
/dev/vda3 40G 39G 0 100% /
/dev/vda2 200M 5.8M 194M 3% /boot/efi
overlay 40G 39G 0 100% /var/lib/docker/overlay2/1a59e3b0b3706a4885b2430cd76739493030fbf58b87a619874965fa71a24bff/merged
overlay 40G 39G 0 100% /var/lib/docker/overlay2/e3cebdce3b5181037d1914e7d20d9b2776b4705d359acb594a2a5ff313eaa655/merged
/dev/loop0 957M 957M 0 100% /mnt
overlay 40G 39G 0 100% /var/lib/docker/overlay2/1a00dbd3a6162515f6803c9a1493e9ec6c1e305bfdb733ad7bf37a730dcb4135/merged
overlay 40G 39G 0 100% /var/lib/docker/overlay2/28a468d669d628e0eb413f9764dd1ba2e608321d650564c71cc73592c11c1c93/merged
tmpfs 188M 0 188M 0% /run/user/0

2. 排查思路

du -sh /* –exclude=/proc –exclude=/sys –exclude=/dev | sort -rh | head -20

发现 /var 占用了 56G（因 overlay2 挂载，实际是 Docker 占用），docker system df 显示容器层占 20GB，镜像占 12GB，docker ps -a –size 显示容器大小

[root@iZwz9i0ey3mo5h7inxu74uZ ~]# du -sh /* –exclude=/proc –exclude=/sys –exclude=/dev 2>/dev/null | sort -rh | head -20
56G /var
6.2G /usr
957M /mnt
190M /boot
43M /data
28M /etc
800K /run
60K /root
20K /tmp
16K /opt
16K /lost+found
4.0K /srv
4.0K /media
4.0K /home
0 /sbin
0 /lib64
0 /lib
0 /bin

[root@iZwz9i0ey3mo5h7inxu74uZ ~]# docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 5 5 12.74GB 678MB (5%)
Containers 5 4 20.83GB 0B (0%)
Local Volumes 0 0 0B 0B
Build Cache 0 0 0B 0B

[root@iZwz9i0ey3mo5h7inxu74uZ ~]# docker ps -a –size
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES SIZE
132f2293 dm8:v1.0 "/opt/dmdbms/bin/dms…" 20 hours ago Up 20 hours 0.0.0.0:15236->5236/tcp, :::5236->5236/tcp dm8 8.86GB (virtual 21.5GB)
f72d52b4 insideo/centos7-java8-build "/bin/bash" 21 hours ago Up 21 hours kind_herschel 12GB (virtual 12.7GB)
45f4f9ef garethflowers/svn-server "/usr/bin/svnserve -…" 23 hours ago Up 23 hours (healthy) 0.0.0.0:13698->3690/tcp, :::3698->3690/tcp svn-server-private 171B (virtual 14.8MB)
9c49f6b7 nginx:alpine "/docker-entrypoint.…" 12 days ago Created download-server 0B (virtual 23.4MB)
b0b35d7b elleflorio/svn-server "/init" 6 weeks ago Up 6 weeks 80/tcp, 443/tcp, 0.0.0.0:3690->3690/tcp, :::3690->3690/tcp svn-server 364kB (virtual 50MB)

3. 解决方案

• 删除废弃容器：停止并删除无用的开发容器（如 Java 编译容器）

• 清理 Docker 缓存：docker system prune -a -f

• 压缩系统日志：journalctl –vacuum-size=200M

• 清空 /mnt 挂载（若有 ISO 镜像）

关键命令：

docker stop <无用容器ID>
docker rm <无用容器ID>
docker system prune -a -f
journalctl –vacuum-size=200M

释放出 10G+ 空间后，数据库才得以继续。

⚠️ 教训：40G 盘跑 Docker + 数据库，必须时刻关注磁盘，必须限制容器日志和数据库归档大小！

三、第二大坑：表空间路径和大小怎么定？

1. 错误的原始写法

CREATE TABLESPACE MZ_SJ_PLATFORM_TS
DATAFILE '/opt/dmdbms/data/DAMENG/MZ_SJ_PLATFORM_TS.dbf'
SIZE 102400 AUTOEXTEND ON NEXT 2048 MAXSIZE UNLIMITED;

• 初始 100GB，远超 40G 磁盘容量

• UNLIMITED 等于自杀

2. 修正后的生产级写法（容器内）

首先进入容器：

docker exec -it <容器ID> /bin/bash

然后执行：

CREATE TABLESPACE MZ_SJ_PLATFORM_TS
DATAFILE '/opt/dmdbms/data/DAMENG/MZ_SJ_PLATFORM_TS.dbf'
SIZE 50 — 初始 50MB
AUTOEXTEND ON
NEXT 20 — 每次扩 20MB
MAXSIZE 2048;— 硬上限 2GB

要点：

• 路径必须是容器内真实存在的目录（如 /opt/dmdbms/data/DAMENG）

• 初始大小和上限必须根据磁盘剩余空间谨慎设置，宁可保守，不可撑爆

• 数据文件放在实例目录（DAMENG）下，便于管理

四、第三大坑：Docker 容器里，JDBC 怎么配？

连接串：

jdbc:dm://localhost:5236/DMSERVER?zeroDateTimeBehavior=convertToNull&useUnicode=true&characterEncoding=utf-8

• localhost：宿主机，因为容器端口 5236 已映射

• DMSERVER：实例名（可通过 SELECT NAME FROM V$INSTANCE; 确认）

• 用户名/密码：使用自己创建的业务用户，而不是默认的 SYSDBA

注意：达梦的 DMSERVER 是实例名，不是物理文件夹名，与数据文件路径无关。

五、第四大坑：导入 dmp 文件，路径和权限是头等大事

1. 将 dmp 拷贝进容器

docker cp imp_exp_20260307103646.dmp 容器ID:/opt/dmdbms/data/backup/

若目录不存在，先 mkdir -p。

2. 进入容器执行导入（常用场景：按模式导入）

docker exec -it 容器ID /bin/bash
cd /opt/dmdbms/bin
./dimp userid=SYSDBA/SYSDBA@localhost:5236 \\
directory=/opt/dmdbms/data/backup \\
file=imp_exp_20260307103646.dmp \\
log=imp.log \\
schemas=原模式名

如果目标模式名不同，用 remap_schema=原模式名:新模式名。

常见错误：

• 用户不存在 → 提前 CREATE USER 并授权

• 表空间不存在 → 提前建好表空间

• 磁盘不足 → 导入前再次 df -h 检查

六、终极教训：小磁盘生存法则

ALTER DATABASE MOUNT;
ALTER DATABASE NOARCHIVELOG;
ALTER DATABASE OPEN;

或在 dm.ini 中设置 ARCH_SPACE_LIMIT = 5120（限制 5GB）。
3. 定期清理 Docker 无用的容器、镜像和卷，可加入 crontab。
4. 监控磁盘：df -h 和 docker system df 应每日查看。

七、总结

达梦在 Docker 中运行并不复杂，但对磁盘空间极度敏感。这次从“根目录爆满”到“完美导入”，每一步都是与有限的资源博弈。希望我的经历能帮你少走弯路，如果你也遇到类似问题，欢迎留言交流。

附录：常用检查命令速查

原创不易，如果本文对你有帮助，请点赞、收藏、关注，你的支持是我分享的动力！