社区版OB4.2.1.2 升级至 OB4.2.1.8 该OB集群有一百多个租户。之前在测试环境升级OB的时候升级任务在 Excute upgrade post script 这个更新租户信息环节消耗了很长时间

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】社区版OB4.2.1.2 升级至 OB4.2.1.8 该OB集群有一百多个租户,大多数租户的资源都是1C6G 这种配置,在升级任务 Excute upgrade post script 更新租户信息的时候会不会消耗很长时间,1C6G租户配置在这个升级环节中会不会有风险。
【 使用版本 】社区版OB4.2.1.2
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):

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

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

用户问题: “从 OceanBase 4.2.1.2 升级到 4.2.1.8,在执行升级后脚本更新租户信息阶段是否会有长时间延迟以及1C6G配置的租户是否存在风险?”

根据您的描述,您正在进行 OceanBase 数据库的版本升级,并且关心在升级过程中更新租户信息阶段是否会遇到长时间延迟的问题,同时询问1C6G配置的租户是否存在风险。

为了更好地了解您的情况并提供准确的帮助,建议您使用 obdiag 工具来采集集群的基础信息,这将有助于我们评估您的环境配置以及可能存在的风险。

日志采集场景: 集群基础信息
日志采集命令: obdiag gather scene run --scene=observer.base

请您执行上述命令并将采集到的日志压缩包提供给我们,以便我们进一步分析。

为了更全面地了解您的情况,请您回答以下几个问题:

  1. 您是在使用 OCP、OBD 还是根据文档手动部署的 OceanBase 集群?
  2. 您的集群是否关联了仲裁服务?如果有关联,请提供相关信息。
  3. 您在升级过程中遇到了具体的错误信息或异常现象吗?
  4. 您的集群中是否有正在进行的关键业务操作,如 DDL、物理备份恢复等?
  5. 您的集群当前的状态如何?是否已经完成了升级?
  6. 您提到的1C6G配置的租户是指 CPU 和内存的具体配置吗?如果是,请提供更多关于该租户的详细信息。

更多信息请查看:

  1. 恢复完成后升级租户
  2. 升级概述
  3. 集群管理 FAQ
  4. 升级 OceanBase 集群
  5. 设置日志同步限速

附上敏捷诊断工具 obdiag 使用帮助链接

之前我看你的帖子 你升级了 让你提供升级后的日志 看你没有回贴 发日志 可以具体看看卡在什么地方了

之前的是测试环境的。那个升级碰到了一个OB的BUG,所以卡在这个环节,找大师看过了。但是数据库可以使用的,黑屏登录显示版本是4.2.1.8

租户量比较大的集群在这个环节升级有没有什么风险,这个是生产环境

正常按照升级流程走是没有问题 主要上次你测试升级的时候 有个Excute upgrade post script没有过去 再升级过程基本上是不要跳过 跳过对后期的数据库也是有风险的 想着你要是有日志 可以先帮你看看 是什么影响的 你找大师看过了 你们是升级到这步 跳过了么?你们升级过后 检查过么?

根据您的补充信息,您在测试环境中遇到了升级过程中的问题,并且已经得到了初步的解决方案,尽管遇到了某个 BUG,但最终数据库能够正常使用,并且显示的版本为 4.2.1.8。现在您关心的是在生产环境中,面对一个拥有大量租户的集群,在执行升级后脚本更新租户信息阶段是否存在风险。

根据文档信息,OceanBase 数据库在升级过程中确实有一些限制和注意事项:

  1. 升级过程中的限制 [2]:

    • 升级过程中会禁止 DDL 操作、Major Freeze、迁移复制和负载均衡、物理备份恢复、Switchover/Failover 操作以及新建租户操作。这些操作在升级完成后会自动开启。
  2. 租户升级命令 [1]:

    • 升级租户可以通过执行 ALTER SYSTEM RUN UPGRADE JOB "UPGRADE_ALL" TENANT = tenant_name; 命令来完成,其中 tenant_name 是需要升级的租户名称。如果集群中有多个租户需要升级,可以一次指定多个租户名称。
  3. 确认升级成功的方法 [1]:

    • 升级后,可以通过查询 oceanbase.GV$OB_PARAMETERSoceanbase.DBA_OB_CLUSTER_EVENT_HISTORY 来确认租户是否成功升级。

针对您提到的1C6G配置的租户,在升级过程中是否存在风险的问题,文档中并没有直接提及。然而,考虑到升级过程中涉及到系统表和数据校验,如果租户数量较多,理论上可能会因为并发处理租户升级而增加时间消耗。但是,只要集群的硬件资源足够,通常情况下升级过程应该是可控的。

风险评估与建议

  • 硬件资源: 确保集群有足够的硬件资源来应对升级过程中的额外负载。
  • 备份: 在生产环境中进行任何重大变更之前,强烈建议进行全面的备份。
  • 测试: 在生产环境升级前,建议在与生产环境配置相似的测试环境中进行完整的升级测试。
  • 监控: 在升级过程中密切监控集群的状态,特别是 CPU 和内存使用情况。
  • 技术支持: 如果有任何不确定的情况,建议提前联系 OceanBase 的技术支持团队获取专业建议。

综上所述,虽然在升级过程中存在一些限制和潜在的风险点,但在合理的准备和监控下,升级过程应该是安全的。如果您在测试环境中遇到的 BUG 已经得到解决,并且数据库在升级后能够正常使用,那么在生产环境中按照相同的步骤进行升级应该也是可行的。不过,鉴于这是生产环境,建议您再次确认所有准备工作,并准备好应急方案。

详情请参考:

  1. 恢复完成后升级租户
  2. oceanbase.DBA_OB_CLUSTER_EVENT_HISTORY
  3. 集群升级
  4. 升级概述
  5. OceanBase 数据库企业版 V4.2.0
  6. OceanBase 数据库 V4.1.0
  7. 升级 OBProxy 集群下全部 OBProxy

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

升级检查 文档 这个升级的检查做了么?
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001052908

upgrade post script这一步还有很多事情要做,1C6G租户配置 CPU配置较低,如果执行升级动作有可能会比较慢,建议扩容下

有个租户出BUG了,所以这个任务跳不过去,这个检查环节是在start zone之后的,所以现在数据库还能用,但是生产环境比较担心。另外,租户名命名时不能命名带有OB数据库含义的名字(例如GTS),不然会出BUG

SELECT * FROM oceanbase.DBA_OB_CLUSTER_EVENT_HISTORY WHERE MODULE=‘UPGRADE’\G。
我看了是目标版本4.2.1.8

如果你的测试环境升级以后 有日志的话 尽量发一下 可以找相关的同学分析一下 看看是否有影响
麻烦找下升级日志:
upgrade_checker.log
upgrade_cluster_health_checker.log
upgrade_post.log
upgrade_pre.log

1 个赞

排查了,升级失败是租户BUG的问题,目前得到修复的方法,准备修复BUG,谢谢

好的 尽量先测试 再升级