【导航台账】制造业数据与AI践行者老蒋的技术博客全系列文章汇总(持续更新)
📌 文章摘要
DolphinScheduler 执行 upgrade-schema.sh 初始化数据库,明明修改了 MySQL 配置却报错连接 PostgreSQL?根本原因是升级脚本通过 DATABASE 环境变量控制 Spring Profile 激活,不设置默认走 postgresql,不读取 application.yaml 配置。本文拆解脚本启动逻辑与环境变量传递链路,给出三种解决方案与优先级建议,照着操作即可避免环境变量隐形坑。
问题现象
兄弟们,前两篇排坑笔记(根据zgenjDolphinScheduler 重启数据全丢?H2 切换 MySQL 完整避坑指南DolphinScheduler 报错 Cannot load driver class?MySQL 驱动路径完整指南、)发出后,有读者私信我:“老蒋,我按照你的步骤改了application.yaml,MySQL也装好了,驱动也放到libs目录了,但执行upgrade-schema.sh的时候还是报错连接PostgreSQL,怎么回事?”
报错信息是这样的:
The following 2 profiles are active: "upgrade", "postgresql" ... Connection to 127.0.0.1:5432 refused.我当时的第一反应是:这不科学啊……
明明已经在tools/conf/application.yaml里把数据库配置改成了MySQL,为什么执行脚本的时候还是去连PostgreSQL?
后来翻了源码和官方文档才发现,DolphinScheduler的upgrade-schema.sh脚本,根本不读application.yaml里的数据库类型配置。
它通过Spring Boot的spring.profiles.active机制来控制激活哪个数据库profile,而这个值来自环境变量DATABASE。
📋 快速自检:你是不是也遇到了这些问题?
▢ 执行 upgrade-schema.sh 报错连接 5432 端口(PostgreSQL 默认端口)
▢ 明明改了 application.yaml 配置,脚本还是不生效
▢ 日志显示 profiles active 为 postgresql,找不到原因
本文一次性解决以上所有问题。
根因分析
第一层:upgrade-schema.sh脚本的启动逻辑
打开tools/bin/upgrade-schema.sh,核心启动命令是这样的:
$JAVA_HOME/bin/java $JAVA_OPTS \ -cp "$DOLPHINSCHEDULER_HOME/tools/conf":"$DOLPHINSCHEDULER_HOME/tools/libs/*":"$DOLPHINSCHEDULER_HOME/tools/sql" \ -Dspring.profiles.active=upgrade,${DATABASE} \ org.apache.dolphinscheduler.tools.datasource.UpgradeDolphinScheduler关键在这里:-Dspring.profiles.active=upgrade,${DATABASE}
${DATABASE}是一个Shell环境变量,脚本会读取它来决定激活哪个数据库profile。
如果你没有设置DATABASE环境变量,它就是空的。Spring Boot会使用默认值,而在DolphinScheduler的配置中,默认的数据库profile是postgresql-11。
所以当你直接执行./tools/bin/upgrade-schema.sh时,实际激活的profile是upgrade,postgresql——这就是为什么它一直去连PostgreSQL的根本原因-。
第二层:环境变量传递链路
整个链路是这样的:
执行 upgrade-schema.sh ↓ 读取环境变量 DATABASE ↓ 如果 DATABASE 未设置 → 默认为空 ↓ Spring Boot 使用默认 profile → postgresql ↓ 连接 127.0.0.1:5432(PostgreSQL默认端口) ↓ 报错:Connection refused
你改了application.yaml没用,因为脚本根本不读它。
第三层:官方文档其实写了,但很多人没注意到
在DolphinScheduler的官方文档里,其实明确写了:
在你的命令行设定下列环境变量:
export DATABASE=mysql、export SPRING_PROFILES_ACTIVE=${DATABASE}
但这段说明藏在“数据源配置”章节的深处,很多人(包括我)在部署时根本没注意到。而且文档里示例用的是export SPRING_PROFILES_ACTIVE=${DATABASE},但在upgrade-schema.sh脚本中实际使用的是${DATABASE}直接拼接,两者略有差异。
解决方案
方案一:执行时临时设置环境变量(推荐,最简单)
DATABASE=mysql ./tools/bin/upgrade-schema.sh执行后,日志中应该看到:
The following 2 profiles are active: "upgrade", "mysql"看到mysql就对了,说明profile已正确激活-。
💡 补充坑:先 export 再执行脚本仍不生效 不注意会怎样:分开执行
export DATABASE=mysql和./tools/bin/upgrade-schema.sh,如果换了终端窗口、或者切换了用户,环境变量就会丢失,依然连 PostgreSQL。 正确做法:将环境变量与脚本写在同一行执行(DATABASE=mysql ./tools/bin/upgrade-schema.sh),变量直接传递给脚本进程,不会丢失。
方案二:修改dolphinscheduler_env.sh永久设置
编辑/opt/dolphinscheduler/bin/env/dolphinscheduler_env.sh,添加:
export DATABASE=mysql export SPRING_PROFILES_ACTIVE=${DATABASE}然后执行:
source /opt/dolphinscheduler/bin/env/dolphinscheduler_env.sh ./tools/bin/upgrade-schema.sh适用场景:需要频繁执行升级脚本、或集群多节点部署的场景;
注意事项:修改环境脚本后必须执行
source命令使其在当前终端生效,重启终端后自动生效。
方案三:直接修改脚本(不推荐,升级会覆盖)
如果不想每次加环境变量,可以直接修改tools/bin/upgrade-schema.sh,将${DATABASE}硬编码为mysql:
-Dspring.profiles.active=upgrade,mysql但不推荐,因为版本升级时这个文件会被覆盖。
验证结果
正确执行后,日志应该是这样的:
2026-08-23 05:10:33.574 INFO --- [main] o.a.d.t.d.UpgradeDolphinScheduler : The following 2 profiles are active: "upgrade", "mysql" ... HikariPool-1 - Start completed.关键标志:
profiles are active: "upgrade", "mysql"→ profile激活正确HikariPool-1 - Start completed.→ 数据库连接成功无
Connection to 127.0.0.1:5432 refused错误
✅ 执行成功三大标志
- ✅日志明确输出:
The following 2 profiles are active: "upgrade", "mysql"- ✅连接池启动成功:
HikariPool-1 - Start completed- ✅无 5432 端口连接拒绝报错,无数据库类异常
经验总结
怕你忘了,我再啰嗦一遍:DolphinScheduler的upgrade-schema.sh通过DATABASE环境变量决定连接哪种数据库,而不是读取application.yaml。DATABASE不设置,默认走postgresql。
落到具体操作上就是三条:
执行
upgrade-schema.sh时必须加DATABASE=mysql:这是最简单的修复方式。加了之后日志会显示"upgrade", "mysql",没加会显示"upgrade", "postgresql"-。application.yaml的修改不是没用,但作用不同:application.yaml控制的是运行时的数据库连接,而upgrade-schema.sh通过环境变量控制。两者都需要配置正确,缺一不可。如果看到
postgresqlprofile被激活,先检查DATABASE环境变量:不用怀疑配置改错了,90%的情况就是忘了设置DATABASE=mysql-。
适用范围:
本文方案适用于所有使用DolphinScheduler Standalone或集群模式,需要通过
upgrade-schema.sh初始化或升级MySQL元数据库的场景。也适用于切换PostgreSQL、H2等其他数据库类型——只需将DATABASE改为对应的值即可。
系列导航
本文属于《数据与AI工程排坑笔记》系列
上一篇:DolphinScheduler数据源连接报错“com.mysql.cj.jdbc.Driver”?JDBC驱动的“路径战争”
下一篇:系列暂告一段落(数仓系列三篇排坑笔记全部产出)
本文问题源自:《制造企业数仓选型实战:为什么我们选了 Apache Doris + DolphinScheduler》《从零搭建 Apache Doris + DolphinScheduler:保姆级步步实操手册(附完整命令)》实战过程,完整源码及深度教程见该文。
💡建议收藏:下次执行
upgrade-schema.sh报错连接PostgreSQL时,先检查是否忘了加DATABASE=mysql。
【热榜文&精品推荐】
TOP1、我用 WorkBuddy 分析了 30 篇 CSDN 博客,发现 3 个反直觉的流量真相
TOP2、还在翻 git log 写周报?WorkBuddy 一键生成结构化周报
TOP3、老攻城狮的AI开发环境搭建全记录:从零到跑通本地大模型(一日速通版)
TOP4、LangChain Agent 反复调用工具死循环?结构化返回 + Prompt 规则
TOP5、智联工坊实战:多工具协同Agent,让AI像人类一样规划与执行复杂任务
TOP6、代码审查不想得罪人?WorkBuddy 先做第一轮审查
互动与交流
你在部署DolphinScheduler时有没有遇到过类似的问题?是不是也折腾了半天才发现是环境变量的问题?欢迎评论区交流,咱们互相支支招——说实话,就因为少加一个环境变量折腾一整天,这事我干过不止一次了。
关于作者
制造业数据与AI践行者老蒋,23年IT老兵。聚焦制造业数据架构与AI融合落地。全流程实战,全源码开源。
标签:#排坑笔记#DolphinScheduler#upgrade-schema#Spring Profile#PostgreSQL#环境变量#数据库初始化#运维踩坑