Vastbase G100 源码解读(三):升级指南——四条升级路径与它们的回滚边界

本文是系列第 3 篇，对应官方文档升级指南章节。

建了个数据库技术交流群，如果你在 Oracle、MySQL、PostgreSQL、Vastbase、OceanBase、GaussDB 等数据库上遇到问题、有选型或运维需求，欢迎进来聊聊。群里蹲着多位数据库行业大咖，踩过的坑、调过的参数、背过的锅，都能给你搭把手。

👉 加群请联系：531968912（备注「数据库」，秒过）

一、先做选择题：我该走哪条路

官方把升级方案归为三类：替换升级、重新初始化升级、补丁升级，其中补丁升级又分 gs_upgradectl 与 VPatch 两个工具[citation:11]。

判断口径记住一条：大版本或 Build 号变了，就别想原地打补丁，走重新初始化[citation:11]。

二、VPatch：解耦 → 单机升级 → 回装

VPatch 的核心设计是"把集群解耦成单机分别升级"[citation:18]：

容灾集群？ ──是──> 先解除容灾关系   │否   ▼HAS 集群解耦（om 卸载集群化管理）   │   ├─ 是否需要先升 HAS？  例：升到 V3.0 Build 8(Patch No.4) 前须先升 HAS V3.5.2[citation:18]   │   ├─ 逐节点 ./vpatch --upgrade   │     ├─ 预检查（版本基线、非打穿包需先二进制替换[citation:28]）   │     ├─ 二进制 + 系统表变更   │     └─ 记录 patch_record_id 到升级历史   │   └─ 重新组集群 / 恢复容灾

回退：

./vpatch --rollback=patch_record_id# 单次回退./vpatch --rollbackTo=patch_record_id# 连续回退（含该记录本身）[citation:30]

红线：修改过数据字典 / 系统表的补丁不支持 rollback，--force 只留给特殊场景并要求厂商介入[citation:30]。

三、gs_upgradectl：就地升级与灰度升级

openGauss 同源工具，两条策略[citation:26]：

gs_upgradectl -t chose-strategy -X cluster_config.xml# 让工具自己选gs_upgradectl -t auto-upgrade  -X cluster_config.xml --grey# 灰度（在线）gs_upgradectl -t auto-rollback -X cluster_config.xml [--force]gs_upgradectl -t commit-upgrade -X cluster_config.xml# 提交，之后不可回退

灰度升级的业务中断通常 < 10s[citation:26]，代价是约束一堆：

• 升级期间不得改 wal_level / max_connections / max_prepared_transactions / max_locks_per_transaction，改了回滚后实例起不来[citation:26]；
• 并发读/写均需 < 200，节点磁盘使用率建议 < 80%[citation:26]；
• 不得同时做扩容/缩容，不支持 VIP，不得手改 version.cfg[citation:26]；
• 主 DN 数据必须已完全同步到备[citation:26]。

commit-upgrade是单行道——提交后 rollback 窗口关闭。社区里"升级成功忘提交 → 参数变更失效"的事故，基本都出在这一步[citation:26]。

四、滚动升级：物理 + 逻辑复制的交接棒

Vastbase 的滚动升级是这套体系里最有意思的部分，本质是把物理复制和逻辑复制接在同一个 LSN 分界点上[citation:13]：

阶段1 建逻辑复制槽   └─ 需等一致性快照；长事务会卡住，catalog_xmin 护住旧版本系统元组阶段2 备库暂停流复制，物理回放至 confirmed_flush阶段3 备库单机升级后改走逻辑复制追增量，盯着 LAG   └─ LAG 设小：追平难；设大：切主停服久阶段4 原主 fast-shutdown 前把未发布日志全部逻辑发布 → 切主 → 其余节点 build 追平

追不平时有两条路：回滚，或业务侧限流[citation:16]。切主瞬间活跃事务会被杀掉，应用必须带重试。

五、升级前检查清单

vsql --version# 1. 确认当前 Build[citation:11]has_ctl status; cm_ctl query -Cv# 2. cluster_state = NormalSELECT * FROM pg_stat_replication;# 3. 主备无延迟SELECT pid, query FROM pg_stat_activity WHERE state='active' AND xact_start < now()-interval '30 min'; -- 4. 清长事务gs_checkos -i A -h $(hostname)# 5. OS 层vb_probackup backup -B /backup --instance dn_6001 -b FULL# 6. 全量物理备份（可 PITR）

再叠加官方版本说明里的专属坑：例如 4.0.0/4.1.0 版 VPatch 有丢系统视图/函数的风险，须先换最新 VPatch 工具包；含自治事务触发器的事件触发器要先关；PG 模式下 COLLATE ... name 升级后不可用[citation:28]。

六、带走什么

升级风险不在于"升"，而在于回滚边界：VPatch 碰了系统表就回不去，gs_upgradectl 一 commit 就回不去，滚动升级 LAG 追不平时只能限流或回滚。先把备份和回退方案写好，再敲命令。

建了个数据库技术交流群，如果你在 Oracle、MySQL、PostgreSQL、Vastbase、OceanBase、GaussDB 等数据库上遇到问题、有选型或运维需求，欢迎进来聊聊。群里蹲着多位数据库行业大咖，踩过的坑、调过的参数、背过的锅，都能给你搭把手。

👉 加群请联系：531968912（备注「数据库」，秒过）