OB4.2.1.2社区版(1-1-1) 升级至 OB4.2.1.8社区版(1-1-1)

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】OCP OB
【 使用版本 】社区版OCP4.2.1 社区版OB4.2.1.2 社区版OB4.2.1.8
【问题描述】采用滚动升级将 OB4.2.1.2社区版(1-1-1) 升级至 OB4.2.1.8社区版(1-1-1)。在升级过程中，是一台observer升级完之后再升级其它的observer吗，对业务有什么影响(业务存在分布式事务)。
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

#3

根据您的问题描述，您希望在生产环境中将 OceanBase 社区版从 4.2.1.2 版本升级到 4.2.1.8 版本，并且关心在滚动升级过程中对业务的影响，特别是考虑到业务中存在分布式事务的情况。

【解答】

  1. 升级过程中的顺序：

    • 滚动升级是指按照一定的顺序逐个升级集群中的节点，而不是一次性升级所有节点。 [5]
    • 在您的情况下，由于集群配置为 1-1-1，意味着有三个 Zone，每个 Zone 内有一个 Observer 节点。因此，升级时会按照 Zone 顺序依次升级每个 Zone 内的 Observer 节点。 [1]

  2. 业务影响：

    • 滚动升级方式不会导致整个集群的服务中断，因为它是逐个 Zone 进行的。这意味着在任何时刻至少有两个 Zone 的服务是正常的，从而保证了业务的连续性和数据的安全性。 [5]
    • 对于分布式事务，OceanBase 设计时已经考虑到了这种场景。在升级过程中，新旧版本的 Observer 节点之间能够兼容工作，确保事务的一致性。 [6]
    • 但是需要注意的是，在升级期间，为了保证数据一致性，可能会暂时禁止某些操作，如 DDL、Major Freeze、Switchover/Failover 等，直到升级完成。 [6]

  3. 具体步骤：

    • 登录 OCP 控制台，选择要升级的集群，然后选择滚动升级方式。 [5]
    • 在升级界面中选择目标版本为 4.2.1.8，并确认所有必要的 RPM 包都已经上传到 OCP。 [5]
    • 点击“升级”按钮启动升级流程。 [5]

  4. 注意事项：

    • 确保在升级前做好数据备份，以防万一升级过程中出现问题。 [6]
    • 升级过程中，建议密切监控集群状态，并准备好应急方案。 [5]

综上所述，采用滚动升级方式将 OB 4.2.1.2 升级到 4.2.1.8 时，是按照 Zone 顺序逐个升级 Observer 节点的。这种方式对业务的影响较小，特别是在处理分布式事务时，OceanBase 的设计能够保证事务的一致性和业务的连续性。 [5], [6]

检索到的文档如下:

  1. 升级 OceanBase 集群
  2. 升级概述
  3. OCP V3.1.2
  4. OceanBase 数据库社区版 V3.1.2
  5. 升级版本
  6. OceanBase 数据库企业版 V4.1.0
#4

既然是数据库升级操作，无论是不是滚动升级，都会对当时数据库的稳定性产生抖动。
还是建议避开业务时候再进行升级

#5

我可以理解在滚动升级过程中，一台observer正在升级，此时租户的分布式事务会自动由另外两台observer提供支持是吗

#6

是的，您的理解是正确的。在滚动升级过程中，当一台 Observer 正在升级时，其余两台 Observer 节点将继续提供服务，确保分布式事务能够正常处理。具体来说：

  1. 分布式事务处理机制：

    • OceanBase 采用多副本机制，通常每个数据分区都有多个副本分布在不同的 Observer 节点上。即使一个 Observer 节点正在进行升级，其他副本仍然可以继续处理事务。 [9]

  2. 高可用性保障：

    • 在 1-1-1 的集群配置中，每个 Zone 有一个 Observer 节点。当其中一个 Zone 的 Observer 正在升级时，其他两个 Zone 的 Observer 节点将继续提供服务，确保事务的一致性和高可用性。 [6]

  3. 事务处理的容错机制：

    • OceanBase 的分布式事务处理机制能够容忍单点故障。在升级过程中，即使一个 Observer 节点暂时不可用，其他 Observer 节点仍然能够继续处理事务，确保业务连续性。 [9]

  4. 具体实现细节：

    • 当一个 Observer 节点正在进行升级时，该节点上的事务处理会被暂停或转移到其他节点。其他两个 Zone 的 Observer 节点将继续处理事务，确保事务的一致性和完整性。 [9]

综上所述，在滚动升级过程中，当一台 Observer 正在升级时，其他两台 Observer 节点将继续提供服务，确保分布式事务能够正常处理。这种机制保证了业务的连续性和高可用性。[6], [9]

检索到的文档如下:

  1. OceanBase 架构
  2. OceanBase 数据库企业版 V4.1.0

更多信息请查看:

  1. 仲裁高可用方案概述
  2. 物理备库概述
  3. 分布式事务
  4. 诊断事务
  5. 分布式执行和并行查询
  6. os_observer_not_exist OB server 进程不存在
  7. 事务数量
  8. 扩展 OceanBase 集群及租户的高可用
  9. 系统架构
  10. 在 OceanBase 数据库上进行 TPC-C 测试

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#7

是的

1 个赞
#8

有两种升级方式
一种是滚动升级，整个过程leader的位置会随着需要升级的节点而变动，升级时间较长但是其他节点能提供服务
另外一种就是所有节点一起升级，升级时间较短但是所有节点都会停止服务，这就根据业务特点和能接受停机时间来决定

1 个赞
#9

已经升过几个集群了，业务低峰操作，影响不大，rt会略微升高。OCP操作，大概20分钟左右。

1 个赞