DBService配置文件丢失导致的启动失败，多数情况下靠备份恢复即可解决，最怕的是两手一摊直接重装，数据丢了连后悔的机会都没有。
配置文件对DBService意味着什么
DBService在华为FusionCompute、GaussDB T等平台里扮演着数据库管家角色，它的配置目录里躺着一堆决定运行参数的文本文件，记录着监听端口、内存上限、数据目录路径、认证方式这些关键信息。配置文件一旦缺失，DBService等同于失忆，压根不知道该连哪个数据目录、该开多大内存、该用哪种加密算法。
实际运维中见过不少人把问题想简单了,他们觉得配置文件丢了就丢了，重新生成一份不就行了？问题在于配置不是凭空生成的，里面耦合了当前集群的握手信息、实例编号、专属密码串，随便拼一个上去，就算进程能起来，上层业务也大概率连不上。
更麻烦的场景是这样的：一套华为FusionCompute环境里跑了上百台虚拟机，DBService挂了之后，计算资源和存储资源的管理面直接瘫痪，界面上所有操作按钮全变成灰色，这时候再做恢复操作，每一分钟都是成本。
行业共识认为,DBService配置文件丢失属于高概率故障类型，导致丢失的原因主要集中在人为误删、磁盘损坏、版本升级中途失败这三个方向。
DBService启动失败排查步骤
配置文件丢失之后,DBService并不会直接告诉你“配置文件没了”，它通常会给出一些模棱两可的报错，比如启动进程后几秒自动退出，或者日志里出现“No such file or directory”，这时候如果经验不足，很容易被表象带偏方向，去排查网络、防火墙、内核参数，绕一大圈回来才发现是配置文件的锅。
第一步：先看日志再动手
日志路径建议直接看这两个位置：
/var/log/Bigdata/DBService/DBService/run.log/var/log/Bigdata/DBService/DBService/start.log
用下面的命令快速过滤：
tail -100 /var/log/Bigdata/DBService/DBService/run.log | grep -i ERROR
如果输出里出现“open config file failed”或“Failed to load config”
这类字样，基本可以锁定指向配置文件，如果出现的是端口占用或者内存不足，那就要另寻方向。
第二步：确认配置目录的实际状态
检查配置文件是否真的丢失,注意关注属主和权限的变化：
ls -la /opt/huawei/Bigdata/DBService/conf/ ls -l /opt/huawei/Bigdata/DBService/conf/dbservice.conf
实际操作中经常遇到的情况是：配置文件还在，但权限被误改成了root属主，DBService以omm用户运行，文件属主不对同样会被判定为“不可读”，表现和文件丢失完全一致，很多人在这一步卡很久，全是权限惹的祸。
第三步：检查数据目录是否完整
配置文件能重新恢复,但数据目录是另一码事，检查数据库物理文件是否存在：
ls -la /var/lib/engines/GaussDBT/ find /var/lib/engines/GaussDBT -name ".data" | wc -l
这一步的意义在于判断恢复成本,数据文件还在，恢复配置属于小问题；数据文件也没了，那就要考虑底层存储是否有快照了。
DBService配置文件丢失怎么恢复
恢复策略取决于手头有什么“存货”。有备份用备份，没备份用同节点复制，两者都没有只能重建，三者的代价差距悬殊。
从备份目录恢复
华为FusionCompute平台本身带有配置备份机制,默认情况下，DBService配置备份位于：
/opt/huawei/Bigdata/DBService/conf_bak/
如果这个目录还存在,直接覆盖回去即可：
cp -r /opt/huawei/Bigdata/DBService/conf_bak/ /opt/huawei/Bigdata/DBService/conf/ chown -R omm:wheel /opt/huawei/Bigdata/DBService/conf/ chmod -R 644 /opt/huawei/Bigdata/DBService/conf/
恢复之后要检查属主和权限,DBService在启动时会对配置文件的读权限做校验，权限过大过小都会导致启动中断。
从同版本集群节点拷贝
多节点的FusionCompute环境里,另一台节点的DBService配置通常具备极高的参考价值，步骤如下：
- 在正常节点上打包配置文件：
tar -czf /tmp/dbs_conf.tar.gz /opt/huawei/Bigdata/DBService/conf/
- 通过安全通道拷贝到故障节点。
- 解压后修改节点专属参数：local.ip、node.id、instance.name。
- 赋权加改属主,然后拉起服务。
值得注意的是,不同节点间配置差异很小，一般集中在IP和实例编号上，只要这两个参数改对了，其余直接沿用问题不大。
无备份时的重建路径
一张表说明白三种方案怎么选：
| 场景 | 恢复方式 | 恢复耗时 | 成功率 |
|---|---|---|---|
| 有近期备份 | 直接回滚配置 | 10分钟内 | 极高 |
| 有同版本存活节点 | 异地拷贝改造 | 30分钟左右 | 较高 |
| 无备份无节点 | 重新初始化 | 1小时以上 | 容易踩坑 |
无备份重建是最后一步棋,流程是先停残留进程、清理半残的配置文件、重新初始化DBService实例目录、再手动启动进程，这一步没有回车键给你按完就万事大吉，后续还要做好几分钟的参数再确认。重建后的配置文件在格式上没问题，但场景化参数容易对不上上层业务的预期。
重启阶段的细节
配置恢复后,启动命令建议用官方脚本而不是直接敲二进制：
su - omm /opt/huawei/Bigdata/DBService/bin/start-dbs.sh
启动之后先观察进程存活状态,不要急着重启FusionCompute整个管理面，给DBService两三分钟稳定期，确认进程没有反复拉起，再看上层业务是否自动恢复连接。
防止配置再次丢落的日常守护机制
恢复一次不难,难的是让这件事不再发生，配置文件丢失之所以频繁出现在运维事故清单里，根子在于正常时没人关注它的存在。
建立按日备份的定时任务
在DBService节点上部署一条crontab,每天凌晨打包配置文件：
0 2 tar -czf /data/dbs_conf_backup/dbs_conf_$(date +%Y%m%d).tar.gz /opt/huawei/Bigdata/DBService/conf/
保留最近七天的备份,同时做异机存放。如果备份只在本地，磁盘坏了备份也跟着陪葬
。
明确配置变更的操作规范
运维人员在调整DBService参数前,必须先备份后修改，FusionCompute里大多数人使用的是图形化界面操作，一些参数在界面提交后会重写配置文件。一旦界面操作期间发生网络中断或提交超时，配置文件就存在被写坏的概率。
规范做法是：变更前快照文件、变更后立即校验文件内容，确认无误后再做业务验证，这中间多花五分钟，能省掉后面折腾两小时的麻烦。
定期巡检文件属主的可信状态
配置文件的属主和权限是ELK日志里最容易体现出的异常信号,把这两项纳入月度巡检脚本，出现异常立即告警，特别是root属主和777权限这类高危状态，看见了就要当场修正。
DBService配置文件是典型的“用时方恨缺”类型。保住配置文件，等于保住数据库的钥匙牌，日常把备份做好了，最坏时刻来临时的回旋余地就大多了。
Q&A：DBService配置文件丢失后优先恢复还是直接重建
问：DBService配置文件丢了，手上没有任何备份，同集群里也没其他存活节点，还有必要尝试恢复吗？
答：有，先检查数据库的数据文件是否完整，完整就有救，用DBService安装包自带的初始化模板重新生成配置文件，然后按数据库实际路径修改目录指向参数，最后启动服务，这套流程在多数情况下能恢复成功。
问：配置文件恢复后，DBService进程还是反复启动失败怎么办？
答：逐项核对配置格式和参数完整性，重点关注文件编码是否为UTF-8、末尾是否有不可见字符、关键节是否被误删，可以用同版本安装包解压出原始配置文件做对比，此外查看/var/log/Bigdata/DBService/DBService/start.log，启动失败一定有明确原因写出，定位到具体行后再对参数做修正。
问：华为FusionCompute里DBService挂掉，虚拟机业务会受影响吗？
答：已运行的虚拟机业务不受影响，但无法创建新虚拟机、无法迁移、无法维护存储资源，管理面临时瘫痪，尽快恢复DBService是唯一出路，每拖延一刻，上层管理操作的积压就多一分。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/586760.html
