物联网后端数据可视化消息队列【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址https://gitcode.com/GitHub_Trending/th/thingsboard点击查看免费下载本文围绕 ThingsBoard Edge 升级流程中的关键环节——**数据库升级upgrade_db**展开以仓库中 upgrade_db.md 为骨架完整梳理「升级前准备 → 安装新版本包 → 执行数据库升级脚本 → 启动服务」的端到端流程并结合upgrade.sh脚本与ThingsboardInstallService源码讲清--fromVersion参数在底层是如何驱动 schema 迁移与实体数据升级的。读完本文你将能够独立、安全地完成一次 ThingsBoard Edge包括 Ubuntu/Debian、CentOS/RPM 与 Docker 三种部署形态的数据库升级并理解升级脚本每一步在做什么。升级总览ThingsBoard Edge 升级的四步工作流在 ThingsBoard Edge 的升级说明中数据库升级并不是孤立的一步而是处于整个升级工作流的中间环节。从 instructions 目录 的组织方式可以看出完整的升级链条升级前准备prepare停止tb-edge服务、备份数据库对应upgrade_preparing.md安装新版本安装包install下载并安装新版tb-edge的 deb/rpm 包或更新 Docker 镜像对应ubuntu/instructions.md、centos/instructions.md、docker/instructions.md升级数据库upgrade_db执行常规升级脚本upgrade.sh --fromVersion${FROM_TB_EDGE_VERSION}即本文主题对应upgrade_db.md启动服务start_service升级完成后重新启动tb-edge服务对应start_service.md。其中第 3 步是升级能否成功落地的关键安装包只是把新的程序文件部署到磁盘而数据库结构必须从旧版本 schema 平滑迁移到新版本 schema这一步正是由升级脚本驱动的。升级前准备停止服务并备份数据库在执行数据库升级之前必须先完成两项准备工作否则升级过程可能因数据文件占用或升级失败无法回滚而带来风险。对应说明见 upgrade_preparing.md。停止 ThingsBoard Edge 服务sudo systemctl stop tb-edge备份数据库升级会对tb_edge数据库执行 DDL结构变更与 DML数据变更因此官方明确要求在升级前完成备份并强调务必确认有足够的磁盘空间存放数据库备份。先检查数据库大小sudo -u postgres psql -c SELECT pg_size_pretty( pg_database_size(tb_edge) );再检查根分区可用空间df -h /若空间充足则执行备份sudo -Hiu postgres pg_dump tb_edge tb_edge.sql.bak备份完成后请确认备份文件已正确生成再进入下一步。安装新版本安装包数据库升级脚本只有在新版本的安装包已部署到位的前提下才有意义——因为升级脚本调用的 jar 与 schema 更新脚本均来自新安装的包。仓库中针对不同操作系统提供了对应的安装说明。Ubuntu / Debiandeb 包对应 ubuntu/instructions.md下载并安装 PE 版安装包wget https://dist.thingsboard.io/tb-edge-${TB_EDGE_TAG}pe.deb sudo dpkg -i tb-edge-${TB_EDGE_TAG}pe.debCentOS / RHELrpm 包对应 centos/instructions.mdwget https://dist.thingsboard.io/tb-edge-${TB_EDGE_TAG}pe.rpm sudo rpm -Uvh tb-edge-${TB_EDGE_TAG}pe.rpm提示安装过程中包管理器dpkg/rpm可能询问如何处理现有的tb-edge配置文件。仓库中的升级说明明确建议选择merge合并选项以保证此前配置的所有参数不会被覆盖丢失。执行数据库升级脚本核心步骤安装完新版安装包后即可执行常规升级脚本。这是 upgrade_db.md 的核心命令sudo /usr/share/tb-edge/bin/install/upgrade.sh --fromVersion${FROM_TB_EDGE_VERSION}其中${FROM_TB_EDGE_VERSION}是一个占位符应替换为当前 Edge 实例已安装的旧版本号即升级前的版本。脚本会依据该参数判断需要从哪个旧版本开始执行 schema 迁移。为什么优先使用 merge 选项该文档开头的 NOTE 是本步骤最容易被忽视的细节Package installer may ask you to merge your tb-edge configuration. It is preferred to usemerge optionto make sure that all your previous parameters will not be overwritten.即包安装器可能询问是否合并tb-edge的配置。官方建议选择merge合并以确保之前设置的参数如数据库连接、JVM 参数、TB_LICENSE_SECRET等不会被新安装包默认值覆盖。这点在 upgrade.sh 的注释中也能得到印证——脚本执行前会source安装目录conf/${pkg.name}.conf中的配置文件若配置在安装阶段被重置升级过程依赖的诸多参数就会丢失。脚本内部做了什么--fromVersion 的底层旅程upgrade.sh 是一个薄封装脚本其核心逻辑如下解析--fromVersion参数脚本遍历命令行参数将--fromVersion*的值提取为FROM_VERSION并去除空白字符作为后续传给 Java 升级程序的版本标识加载配置文件通过source ${CONF_FOLDER}/${configfile}引入tb-edge.conf并据此确定运行用户、安装目录等环境信息清理历史遗留产物例如删除旧的rule-node-twilio-sms*.jar扩展包避免其通过LOADER_PATH遮蔽核心类库以安装用户身份调用 Java 升级程序su -s /bin/sh -c java -cp ${jarfile} $JAVA_OPTS \ -Dloader.mainorg.thingsboard.server.ThingsboardInstallApplication \ -Dinstall.data_dir${installDir} \ -Dspring.jpa.hibernate.ddl-autonone \ -Dinstall.upgradetrue \ -Dinstall.upgrade.from_version${fromVersion} \ -Dlogging.config${pkg.installFolder}/bin/install/logback.xml \ org.springframework.boot.loader.launch.PropertiesLauncher $run_user关键参数包括-Dinstall.upgradetrue声明本次运行为升级模式-Dinstall.upgrade.from_version${fromVersion}将命令行传入的版本号传递给升级程序-Dspring.jpa.hibernate.ddl-autonone表示不依赖 JPA 自动建表schema 变更完全交由升级脚本控制 5.捕获并上报退出码脚本将升级程序的退出状态保存为upgradeStatus失败时输出ThingsBoard upgrade failed!成功时输出ThingsBoard upgraded successfully!并以该状态码退出供上层包装脚本判断升级结果。升级程序在服务端做了什么源码级拆解upgrade.sh调用的ThingsboardInstallApplication入口位于 ThingsboardInstallApplication.java最终进入 ThingsboardInstallService.java 的performInstall()方法。其中两个Value注入点与本文命令直接对应Value(${install.upgrade:false}) private Boolean isUpgrade; Value(${install.upgrade.from_version:}) private String upgradeFromVersion;performInstall()在升级分支中依次完成以下动作源码第 88 行起的performInstall方法校验 schema 版本调用databaseSchemaVersionService.validateSchemaSettings()确认数据库当前 schema 版本处于受支持的升级区间内升级前许可证预检调用licenseCapacityUpgradePreflight.check()在写入任何数据前校验实例持有的设备数量是否仍在许可证覆盖范围内避免对已转换的数据库做事后拒绝源码注释原文Before anything is written, so an upgrade the resulting license would not cover is refused now rather than on an already converted database清理缓存cacheCleanupService.clearCache()执行 schema 更新脚本databaseEntitiesUpgradeService.upgradeDatabase(updateFromCE)应用schema_update.sql——该脚本可能包含对既有表结构的 DDL 变更以及对库内记录的 DML 操作。这些脚本按版本目录组织在 application/src/main/data/upgrade 下例如basic/schema_update.sql 与 pe/schema_update.sqllts/4.4.0.0/schema_update.sql、lts/4.3.1.6/schema_update.sql 等按 LTS 版本组织的升级脚本链补建无数据的新表entityDatabaseSchemaService.createDatabaseSchema(false)自动创建所有尚无数据的全新表重建视图与函数createOrUpdateViewsAndFunctions()、createOrUpdateDeviceInfoView(persistToTelemetry)确保视图与函数定义与新版 schema 一致创建缺失索引createDatabaseIndexes()运行 SQL 无法完成的升级通过dataUpdateService.upgradeRuleNodes()等方式执行无法以纯 SQL 实现的规则节点等数据升级并将数据库标记为已升级重复运行会被拒绝。从这段源码可以推断--fromVersion参数不仅决定从哪条版本链开始执行迁移还决定了升级程序走哪条分支——例如cassandra-latest-to-postgres与postgres-to-citus是独立的特殊迁移路径源码 91115 行而常规升级分支则执行上文的标准 schema 升级流程。Docker 部署形态下的数据库升级对于以 Docker Compose 部署的 ThingsBoard Edge升级流程有独立的一套说明见 docker 目录数据库升级同样在其中扮演核心角色。Docker 版升级前准备对应 docker/upgrade_preparing.md在包含docker-compose.yml的目录下先停止并移除正在运行的 TB Edge 容器docker compose stop docker compose rm mytbedge再对数据库 volume 做备份docker run --rm -v tb-edge-postgres-data:/source -v tb-edge-postgres-data-backup:/backup busybox sh -c cp -a /source/. /backupDocker 版数据库升级对应 docker/upgrade_db.md创建一个专门的升级 compose 文件 docker-compose-upgrade.yml nano docker-compose-upgrade.yml写入以下内容注意entrypoint: upgrade-tb-edge.sh会将容器入口指向升级脚本即与裸机部署的upgrade.sh相对应的容器化版本services: mytbedge: restart: on-failure image: thingsboard/tb-edge-pe:${TB_EDGE_VERSION} environment: SPRING_DATASOURCE_URL: jdbc:postgresql://postgres:5432/tb-edge volumes: - tb-edge-data:/data - tb-edge-logs:/var/log/tb-edge entrypoint: upgrade-tb-edge.sh postgres: restart: always image: postgres:15 ports: - 5432 environment: POSTGRES_DB: tb-edge POSTGRES_PASSWORD: postgres volumes: - tb-edge-postgres-data:/var/lib/postgresql/data volumes: tb-edge-data: name: tb-edge-data tb-edge-logs: name: tb-edge-logs tb-edge-postgres-data: name: tb-edge-postgres-data随后启动升级进程docker compose -f docker-compose-upgrade.yml up --abort-on-container-exit--abort-on-container-exit保证升级容器mytbedge一旦退出整个升级 compose 即随之结束便于明确判断升级完成状态。升级完成后启动服务数据库升级成功结束后即可重新启动 ThingsBoard Edge 服务。裸机部署Ubuntu / CentOS对应 start_service.mdsudo systemctl tb-edge start注意该说明文件原文如此命令形态与标准的sudo systemctl start tb-edge略有差异实际操作时请以你所用发行版与安装包文档为准也可直接使用sudo systemctl start tb-edge。Docker 部署对应 docker/start_service.md先修改主docker-compose.yml将镜像更新为新版本并确保为thingsboard/tb-edge-pe:${TB_EDGE_VERSION}nano docker-compose.ymlservices: mytbedge: restart: always image: thingsboard/tb-edge-pe:${TB_EDGE_VERSION} ...然后启动并观察日志docker compose up -d docker compose logs -f mytbedge常见问题与操作要点小结版本号占位符${FROM_TB_EDGE_VERSION}与${TB_EDGE_TAG}、${TB_EDGE_VERSION}均为升级说明中的占位符实际执行时需替换为具体版本号--fromVersion必须填写当前实例的旧版本脚本才能确定从哪条 LTS/版本链开始迁移merge 配置优先安装包询问配置处理方式时选择 merge避免旧参数被覆盖这是upgrade_db.md最强调的注意事项备份不可省略升级涉及 schema DDL 与数据 DML官方在upgrade_preparing.md中明确要求先备份tb_edge数据库并确认空间充足升级顺序不可颠倒必须先部署新安装包、再执行upgrade.sh --fromVersion...最后启动服务重复运行升级脚本会被数据库中的升级标记拒绝源码注释marked as upgraded and a re-run refused失败可辨识upgrade.sh会以升级程序的真实退出码返回含许可证预检拒绝等前置失败便于脚本化升级时捕获失败状态。如需继续深入可在仓库中进一步阅读 upgrade.sh 的完整实现、ThingsboardInstallService.java 的performInstall()流程以及 application/src/main/data/upgrade 下按版本组织的schema_update.sql迁移脚本以掌握每一次版本升级对数据库结构的具体改动。赞分享物联网后端数据可视化消息队列【免费下载链接】thingsboardAll-in-one IoT Platform - Device management, data collection, processing and visualization.项目地址https://gitcode.com/GitHub_Trending/th/thingsboard点击查看免费下载相关推荐ThingsBoard Edge Docker 数据库升级完整指南upgrade_db 配置模板解析与升级流程实战ThingsBoard Edge Docker 数据库升级完整指南upgrade_db 配置模板解析与升级流程实战 本文以 ThingsBoard 开源仓库中物联网后端数据可视化消息队列ThingsBoard Edge Ubuntu 升级指南基于 .deb 包的升级流程与实现原理ThingsBoard Edge Ubuntu 升级指南基于 .deb 包的升级流程与实现原理 本篇技术指南围绕 ThingsBoard Edge 在 Ubu物联网后端数据可视化消息队列ThingsBoard Edge 基于 Docker 的版本升级实战指南从准备工作到数据库迁移全流程ThingsBoard Edge 基于 Docker 的版本升级实战指南从准备工作到数据库迁移全流程 本文以 ThingsBoard 仓库中 Edge 的 D物联网后端数据可视化消息队列创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考