openEuler + 达梦 DM8 + openGauss：RuoYi Office 多库部署与运行维护实践

🌐 文档地址：https://ruoyioffice.com
👇 文章底部获取源码和演示地址 👇
💬 ：17156169080（获取产品咨询）

一套应用支持多个数据库，运维仍然需要明确当前连接哪一个库、读取哪份参数、使用哪个数据基线。本文以 RuoYi Office 的 openEuler 实验室为例，讲清达梦与 openGauss 的环境切换、服务启动、健康检查和业务复核，并区分环境切换与数据迁移。

▲ 控制台是运维逻辑示意，不是平台新增功能截图：先停止应用、准备目标数据库、启动对应 Profile，再检查产品结果。

引言：同一个应用包，为什么切库后会看到另一批单据？

多库部署中，数据库身份和应用包身份是两个维度。同一个 JAR 可以连接达梦，也可以连接 openGa
uss；两边数据库保存的记录并不会因此自动同步。

切换后看不到原来的单据，可能只是目标库拥有另一份数据基线。若把环境切换误认为无缝数据迁移
，运维人员容易在错误环境中继续操作。

同样，浏览器仍显示旧标签页，后台却已连接新库，也可能产生看似矛盾的界面信息。切换完成后需
要重新登录并核对环境与代表记录。

操作	实际改变	不会自动完成
切换 Profile	驱动、URL、策略等运行配置	复制业务数据
启动目标数据库	目标数据服务可运行	验证全部结构与内容
更新 JAR	应用代码与依赖	补齐目标库增量
更新前端资源	浏览器界面代码	清理所有旧客户端状态
健康检查 UP	应用报告健康	代表审批闭环

运维实践的核心，是让应用、参数、数据库和产品观察始终对应同一个环境身份。

一、用户看到的页面，怎样用于运行检查

RuoYi Office 的多库运行复核可以沿用产品页面：先登录工作台，再打开代表单据与流程。用户界
面让技术检查落到实际功能，而不只停在 systemd 状态。

1. 登录与工作台检查身份和模块入口

▲ 既有开发环境实拍，展示运行检查入口；它不是当前达梦或 openGauss 环境状态的截图。

环境切换后，建议用获准账号重新登录，核对租户、组织和菜单。共享 Redis 不代表两个数据库的
用户、权限和业务记录天然一致。

不应把清空整个 Redis 作为切库的默认动作。先核对应用会话策略和缓存命名，避免为了排查一个
环境而影响其他服务。

2. 单据详情检查数据基线与时间

▲ 本地既有单据实拍，用于说明代表记录检查；切库时应使用目标环境的获准样本。

核对单号、中文、业务状态与日期时间。单据详情比列表更容易发现基础资料关联、字段缺失和时间
契约变化。

3. 流程详情检查引擎与业务关联

▲ 既有开发环境用车审批详情，展示业务身份与流程上下文；国产库切换后的实际结果须在目标库取得。

查看已有流程与创建新流程覆盖不同路径。前者偏重查询，后者会触发新 ID、运行表写入和业务回
调。

因此切换后的最小复核应至少包含读路径；需要投产验收时，再执行获准的代表提交与审批。

二、先给每个运行环境一个明确身份

实验室将数据库环境命名为 dm8、opengauss 和 postgres，分别对应环境文件和 systemd 实
例。本文重点讨论前两者，PostgreSQL 用作兼容对照。

1. 环境参数与服务实例一一对应

项目	达梦	openGauss
systemd 应用实例	ruoyi-office@dm8	ruoyi-office@opengauss
参数文件	/etc/ruoyi-office/dm8.env	/etc/ruoyi-office/opengauss.env
Profile	prod,xinchuang-dm8	prod,xinchuang-opengauss
JDBC	DM 官方驱动	openGauss 官方驱动
schema	RUOYI_OFFICE	ruoyi_office
主键策略	AUTO	INPUT / 序列

环境文件保存连接参数和堆参数，不应把真实密码放入 Git。现有部署脚本将环境文件设为 0600
，但现场还应核对所有者与服务账号读取方式。

systemd 读取环境文件与 Java 程序读取一个任意配置文件，不是同一种权限路径；排查时要看实际
启动日志，不能只凭文件模式推断应用必定拿到了变量。

2. 同一包包含多驱动，不代表同时运行多个实例

实验室共用后端端口，设计上同一时刻运行一个应用 Profile。数据库运行时可以独立存在，应用选
择其中一个目标环境。

多个数据库容器存在，并不会自动造成应用端口冲突；多个应用同时绑定相同后端端口才会冲突。

如果客户需要并行运行两套应用，应为端口、接入路由、上传目录、缓存与调度命名空间建立独立规
划，不能直接复制本实验室切换脚本。

3. 日志也要体现环境身份

专用 Profile 使用不同应用日志文件名，systemd 实例日志也可以按 @dm8 或 @opengauss 查
询。

建议排查时同时记录数据库 URL 的非敏感部分、Profile、日志时间和请求路径。不要把另一环境的
历史启动成功行当成当前实例成功。

三、现有切换脚本实际做了什么

1. 停止应用，再准备缓存与目标数据库

当前脚本先停止三个应用实例，准备 Redis，再启动目标数据库运行时。openGauss 可以是容器，也
可以是系统服务，脚本分别处理。

if podman container exists ro-redis; then
  podman start ro-redis >/dev/null
else
  systemctl start redis
fi
if podman container exists "${container}"; then
  podman start "${container}" >/dev/null
elif [[ "${db}" == "opengauss" ]]; then
  systemctl start opengauss
else
  echo "Database runtime is missing for ${db}" >&2
  exit 2
fi
systemctl start "ruoyi-office@${db}.service"
systemctl --no-pager --full status "ruoyi-office@${db}.service"

这里应注意：停止应用使用了容错处理，存在 || true。它方便处理“原实例本来就不存在”等情况
，但也意味着不能仅凭脚本继续执行，就宣称所有旧应用已经成功退出。

现场应查看实例状态、端口与进程身份，确认只留下目标应用。本文不修改现有切换工具，而是明确
其使用边界与运行检查要求。

2. 服务启动不等于数据库就绪

podman start 或 systemctl start 返回成功，通常说明启动动作已完成，不代表数据库已能接
受认证查询。

应用可能在数据库恢复期间开始连接。现有 systemd 提供异常重启，仍应把数据库就绪检查放到实
际交付流程中，避免重复启动掩盖错误密码或缺表。

观察项	能回答的问题	后续检查
容器 / 服务 active	运行时是否存在	数据库认证与查询
后端端口监听	应用是否绑定端口	实例身份与健康
Actuator UP	应用完成健康检查	登录与代表页面
工作台正确	身份与部分查询可用	新增与审批
代表流程一致	业务链路可用	客户启用模块回归

3. 用 systemd 把实例名带进 Profile

现有服务单元读取 %i.env，并把 %i 写入 xinchuang-%i。这将环境文件名和 Profile 关联
，减少人工分别修改多处参数的机会。

[Unit]
Description=RuoYi Office (%i database)
After=network-online.target tengine.service opengauss.service redis.service
Wants=network-online.target

[Service]
Type=simple
User=roadmin
Group=roadmin
WorkingDirectory=/data/ruoyi-office/app
EnvironmentFile=/etc/ruoyi-office/%i.env
ExecStart=/usr/bin/java -Xms${JAVA_XMS} -Xmx${JAVA_XMX} -Dfile.encoding=UTF-8 -jar /data/ruoyi-office/app/yudao-server.jar --spring.profiles.active=prod,xinchuang-%i
SuccessExitStatus=143
Restart=on-failure
RestartSec=10
LimitNOFILE=65535

After 不是健康探针，Restart 也不是数据修复。应用失败时，应按“配置 → 数据库就绪 → 结
构基线 → 引擎 → 业务请求”的顺序定位。

四、把服务关系变成可核对资产

1. 应用实例与数据库数据独立管理

▲ 运行资产逻辑图：应用实例读取环境文件，连接独立数据库，并产生自身日志；这是运维关系模型，不是新增数据库表。

资产	切换时怎样处理	不能混淆的责任
应用包	复用或按版本更新	不保存全部业务数据
环境文件	选择目标参数	不完成数据同步
数据库目录	独立持久保存	不随 Profile 切换复制
前端资源	与应用版本配套	不提供数据库恢复
上传目录	独立备份与映射	不因业务表导入自动出现
日志与证据	按环境保留	不用历史日志替代当前结果

如果切换同时升级应用包，应核对目标数据库是否应用了配套增量。多个库拥有不同历史基线时，不
能默认“一次升级全部环境都已经就绪”。

2. 顺序图说明每一步的失败位置

▲ 环境切换先处理应用与运行时，再进入健康与产品检查；数据迁移属于独立流程，不在切换步骤里隐式执行。

设计决策	当前做法或建议	原因
单实例	共用端口，仅启动目标 Profile	实验室减少并行变量
参数外置	实例名对应 env 文件	环境身份可解释
数据持久化	不同数据库独立目录	避免混用数据基线
健康递进	运行时 → 应用 → 产品	逐层缩小故障范围
切换后登录	重新建立目标业务上下文	降低旧页面状态误读

五、健康检查怎样等待才不会误判

历史实验中，达梦和 openGauss 的应用启动约为 145 秒和 153 秒。这是当时虚拟机与基线的观察
，不是性能承诺。

如果检查脚本只等十秒，就可能把仍在正常启动的实例判成失败。反过来，无限等待会掩盖持续重启
或固定配置错误。

下面是可用于交付的健康等待设计示例。它限定时间、逐次请求、核对实际 JSON 状态，最后返回清
楚的失败结果；不是声称现有切换脚本已自动执行了它。

#!/usr/bin/env bash
# 建议的健康等待方式：不执行重启，不修改数据
set -euo pipefail
health_url="http://127.0.0.1:48080/actuator/health"
deadline=$((SECONDS + 240))
while (( SECONDS < deadline )); do
  body=$(curl -fsS --connect-timeout 2 --max-time 5 "$health_url") || body=''
  if printf '%s' "$body" | python3 -c '
import json, sys
try:
    payload = json.load(sys.stdin)
except (ValueError, TypeError):
    sys.exit(1)
sys.exit(0 if payload.get("status") == "UP" else 1)
'; then
    echo "Application health: UP"
    exit 0
  fi
  sleep 5
done
echo "Health check timed out; inspect service and database logs" >&2
exit 1

HTTP 200 与 JSON 中的 UP 分别检查，防止意外 HTML 页面或错误代理返回被当作健康结果。

等待期间若看到服务不断重启，应直接查询首个启动异常。超时后不要立即连发多次重启，先确认当
前进程是否仍在启动。

六、切换之后，怎样解释页面与数据变化

1. 单据不同，先核对数据库身份

同一应用包连接另一数据库时，记录数量、用户和流程模型可能不同。这是数据基线差异，不必然是
功能丢失。

先核对当前 Profile、数据库名称与代表单号，再判断是否迁移遗漏。不要从页面数据不同直接推断
数据库不兼容。

2. 模型存在，仍要核对运行定义

历史 openGauss 问题说明模型、部署与可执行定义需要分别核对。环境切换后，如果发起入口为空
，应检查定义与权限，而不是只对比模型总数。

新数据写入失败时，还要检查序列、主键策略与最新增量。旧单据能查询，不表示当前新增路径已经
验证。

3. 文件和外部组件不随数据库自动切换

附件表中的记录可能引用磁盘、对象存储或外部预览服务。切换到另一数据库时，需要核对文件路径
和服务参数是否与目标数据配套。

OnlyOffice、短信、邮件和外部身份系统同样有自己的配置与网络要求。数据库连接成功不能证明这
些服务已经完成切换。

七、回退环境与回退数据是两件事

切回旧 Profile，只是重新连接旧数据库。它不会把新库期间创建的数据带回，也不会撤销旧库已经
执行的结构变更。

如果项目在迁移后已经产生新业务，应先明确哪些记录需要回迁、哪些外部动作已经发生，再决定是
否能够回退。

场景	需要恢复的资产	主要核对
实验室换库	原 Profile 与独立数据	旧实例能否启动
应用版本回退	前后端包与参数	数据结构是否兼容
数据库恢复	备份与升级记录	业务事实是否完整
完整服务恢复	数据库、文件、参数与应用	引用与状态是否一致

历史记录验证了 PostgreSQL 适配后切回达梦，应用健康为 UP。这个结果不能扩大成“所有数据库切
换后全部模块均完成回归”。

1. 保留恢复点的输入身份

备份应记录数据库版本、schema、应用基线与文件范围。只有备份文件而没有恢复步骤，不能证明现
场具备可用恢复能力。

2. 恢复演练也要回到产品链路

恢复后检查用户与代表单据、流程历史、文件访问和新增路径。单看数据库服务 active，只完成了
恢复链路的一小段。

对于有外部消息或支付动作的项目，还需处理外部状态；数据库恢复不会自动撤销已经送达的外部通
知。

八、交付给下一位运维人员的运行清单

一份可复用运行说明，应该让接手的人不依赖原实施者记忆，也能确认当前环境和下一步动作。

1. 标明当前目标数据库、版本与 schema。
2. 标明应用和前端产物版本。
3. 列出实例名称、参数文件和日志位置。
4. 列出数据库运行时与持久化目录。
5. 给出停止、启动与状态观察方法。
6. 给出健康等待与超时定位方法。
7. 固定代表用户、单据与流程检查路径。
8. 明确备份范围、恢复步骤和未覆盖组件。

运行说明不应包含真实密码。保密参数应由客户批准的凭据管理方式交付，文章和 Git 只保留参数
名称与结构。

一次切换排障怎么做：把“启动不了”拆成具体观察

假设从达梦切换到 openGauss 后，浏览器暂时打不开工作台。

先停止增加新的变更，沿实例、端口、健康和页面逐层定位。

检查原实例是否已经退出

查看三个应用实例状态，再核对后端端口对应的实际进程。

若旧进程尚未结束，不要立即启动多个新实例竞争同一端口。

如果停止失败，保存错误原因并按实际服务状态处理。

这项观察补足现有脚本停止阶段的容错边界，防止把“命令继续”当成“停止成功”。

检查目标数据库是否接受连接

数据库容器 active 后，继续进行获准的认证与只读查询。

连接拒绝、认证失败和对象不存在，分别指向运行时、凭据或 schema。

不能把这三种问题都用延长健康等待来处理。

等待解决的是尚未就绪，不解决固定错误。

检查应用是否正在启动还是反复退出

查看本次实例日志的时间线。

一次持续启动与多次相同异常重启，有不同含义。

如果日志一直重复驱动或缺表错误，应核对依赖与基线，而不是继续扩大超时。

如果启动正常推进，则等待健康结果，不在中途反复触发重启。

检查 Tengine 与应用之间的请求

应用本机健康正常，而浏览器仍失败时，检查接入和实际 API 响应。

静态脚本返回 HTML、API 代理地址错误和客户端缓存，都会产生页面异常。

此时数据库可能已经正常，重新导入数据只会引入更多变化。

定位顺序应由真实请求结果决定。

观察结果	更可能需要检查的内容
端口被旧进程占用	原实例停止与进程身份
数据库认证失败	env 参数与目标账号
应用反复缺表退出	schema、初始化与增量
本机健康正常，页面白屏	资源前缀、响应类型与缓存
工作台正常，新增失败	主键、序列与运行时 SQL
历史正常，附件失败	文件资产与外部服务

环境已经切回，怎样判断这次恢复成功

重新登录，核对目标数据库与代表数据。

再打开一张已知单据，观察字段、关联与流程身份。

需要写入验收时，执行获准代表用例，而不是仅重复查看旧记录。

恢复说明应记录切换时间、实际目标、失败阶段和复核结果。

为什么备份范围要包含文件

单据与附件记录可能引用磁盘或对象存储中的内容。

只恢复数据库，可以恢复引用，但不会凭空恢复文件。

文件与数据库分别备份时，需要确认恢复点之间是否配套。

否则一张单据可能恢复到昨天，关联文件却只保留今天的内容。

运行检查哪些适合自动化

服务状态、健康 JSON 和明确只读查询，适合脚本重复执行。

审批动作、恢复和数据迁移则有实际业务副作用，应使用获准测试安排。

自动化输出应说明执行对象与时间，不能把上次 PASS 无限沿用。

也不必把每次页面检查都扩大成全库操作。

检查类型	适合的执行方式	记录内容
服务状态	systemd / 容器观察	实例与时间
应用健康	有界等待与 JSON 核对	当前健康结果
数据基线	只读检查	schema 与代表对象
页面入口	浏览器读取	身份与实际页面
审批写入	获准代表用例	单号与结果
恢复演练	获准恢复安排	输入资产与恢复结果

这套顺序让运维人员先取得事实，再决定动作，减少不必要的重新部署与数据处理。

九、快速体验

在线演示：https://ruoyioffice.com/web/

使用 admin / admin123 查看工作台、用印详情和已有流程结果，理解切换后要复核的产品对象。

多库切换工具位于交付工程 xinchuang-lab/guest/switch-db.sh。它用于已准备好的实验环境；
客户生产切换需要自己的停写、备份、恢复与验收安排。

常见问题（FAQ）

切换达梦与 openGauss，需要重新编译应用吗？

在当前已打包相应驱动、且应用版本匹配的方案中，可以复用同一 JAR，通过 Profile 与环境参数
选择目标库。数据基线与配置仍需独立准备。

切换 Profile，会把达梦数据同步到 openGauss 吗？

不会。环境切换选择数据库连接，数据迁移需要独立的转换、导入和核对流程。

systemd 显示 active，为什么页面还暂时打不开？

服务 active 不等于 Java 应用已经完成启动。需要等待健康结果，并观察数据库就绪、初始化和首
次启动日志。

可以同时启动两套 Profile 吗？

本实验室共用后端端口，按单应用实例切换。并行部署需要重新规划端口、接入、缓存、文件和调度
边界。

结语：让运行环境始终可以被解释

多库能力提供选择，运行维护负责让选择清楚地落到参数、实例、数据和产品结果。

RuoYi Office 用独立 Profile、环境文件和服务实例组织多库部署，让同一套产品能在不同数据库
环境中接受验证。持续运维则需要把环境身份、健康状态与代表业务一起检查，避免把换连接误读为
换数据。

你的部署清单里，是否能直接找到“当前连接哪个库、对应哪份基线、恢复要带哪些文件”？这三项通
常比一条启动命令更能帮助接手人员。

系列阅读

• openEuler + 毕昇 JDK + Tengine：RuoYi Office 国产化部署实战
• SpringBoot3 + 达梦 DM8：RuoYi Office 用印申请与多级审批实战
• SpringBoot3 + openGauss：RuoYi Office 登录、流程发布与用印填报适配实战
• 达梦 DM8 + openGauss：RuoYi Office 的 MySQL 数据转换与导入实践
• 达梦 DM8、openGauss、人大金仓怎么选？RuoYi Office 国产数据库适配与验收指南

如果这篇对你有用，点个「在看」或收藏。

🌐 演示地址：https://ruoyioffice.com/web
📦 GitHub 源码：https://github.com/yuqing2026/ruoyi-office
📦 Gitee 源码：https://gitee.com/yqzy1688/ruoyi-office
💬 微信：17156169080（获取产品咨询）

打开演示地址直接查看系统。