很多开发者在本地跑通了 DolphinDB 之后，就觉得万事大吉了。但真正上了生产环境，才发现运维才是最容易翻车的地方——磁盘悄悄满了、关机没确认进程、随手删了个目录……本期我们把最常见的运维坑和日常管理问题整理出来，希望你看完之后，可以提前避坑，不再需要事后补救。
安全关机，别想当然
DolphinDB 的安全关机需要执行 stopSingle.sh 或 stopAllNode.sh 脚本文件，而不是立刻停止进程，在关闭前会先完成事务刷盘，所以关机过程可能比你预期的慢。
关键点： 执行关机命令后，务必确认进程已完全退出，再执行重启。如果进程还没退出就重启，节点端口仍处于绑定状态，会导致重启失败。
磁盘空间，一定要监控
磁盘问题是最常见、也最隐蔽的“生产事故触发器”。磁盘满了会发生什么？写入失败、数据不完整、系统卡死——而且往往很难快速恢复。
建议将磁盘使用率纳入监控体系，设置合理的告警阈值，在达到阈值时及时介入，定期清理历史日志、临时文件、无用表或分区，不要等到磁盘真的满了再处理。
数据迁移：用对工具，别走捷径
迁移数据时，有人会直接拷贝底层数据文件——这是个危险操作。底层文件的直接拷贝容易造成数据不一致或元数据缺失，迁移后的数据可能无法正常读取。
正确做法：
-
备份：使用 backup 系列函数
-
恢复/导入：使用 restore 系列函数
具体可参考教程：数据备份以及恢复
docs.dolphindb.cn/zh/tutorial…
系统文件：禁止随意修改或删除
DolphinDB 的部署目录及以下配置的数据存储目录，均为系统运行的核心依赖，不可随意改动：
-
dfsMetaDir
-
chunkMetaDir
-
volumes
-
TSDBRedoLogDir
-
persistenceDir
-
computeNodeCacheDir
配置数据存储路径时，统一在路径中加入 DolphinDB 子目录，并结合节点别名（）进行区分。其中， 通常表示节点的唯一标识。如果多个节点共用同一个目录，可能会导致数据覆盖、元数据混乱，甚至引发服务异常。因此，建议在所有数据目录（如 chunkMetaDir、dataDir 等）中都统一引入 <ALIAS>，确保各节点之间完全隔离。
例如：
chunkMetaDir=/ssd/ssd1/DolphinDB/chunkMeta/<ALIAS>
这样一眼就能识别出哪些是 DolphinDB 的数据目录，大大降低误操作风险。
危险操作清单：做之前先咨询技术支持
以下操作一旦出错，轻则节点无法启动，重则数据丢失。强烈建议在执行前咨询 DolphinDB 技术人员，并在其指导下进行：
-
磁盘操作：挂载、卸载、扩容、缩容、更换
-
修改 hostname
-
修改 IP
-
修改数据存储目录配置：volumes、dfsMetaDir、chunkMetaDir、redoLogDir、TSDBRedoLogDir
日常管理 Q&A
1.升级 server 或更新 license，必须重启集群吗？
-
升级 server：必须重启。
-
更新 license：分以下两种情况
-
在线更新：使用 updateLicense 函数，或 ops 运维库中的 updateAllLicenses 函数，无需重启。注意在线更新有一定的限制条件，详见官方文档「高可用集群部署与升级 — 授权许可文件过期更新」。
-
离线更新：替换 license 文件后重启即可。
2.普通用户怎么改自己的密码？
changePwd(oldPwd, newPwd)
3.怎么统计数据库或数据表占用的磁盘空间？
使用 ops 运维库中的 getTableDiskUsage 函数。
use ops
getTableDiskUsage("dfs://your_database", "your_table")
4.怎么查看用户的内存使用情况？
getSessionMemoryStat()
返回各 session 的内存占用详情，排查内存异常时非常实用。
运维的很多问题，并不是“技术难”，而是发生时已经太晚了。你可以不记住所有细节，但至少要建立三个意识：
-
不确定的操作，不要直接在生产做
-
系统目录，不要手动碰
-
磁盘和资源，一定要监控
如果你在实际使用中遇到过“经典事故”，也欢迎分享，我们可以在后续专题里继续补充。
