通过 obd 升级 oceanbase-ce 失败

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境
测试环境

【 OB or 其他组件 】
obd，oceanbase-ce

【 使用版本 】
obd：2.10.1，oceanbase-ce：4.2.1.10

【问题描述】清晰明确描述问题
安装官方文档，执行 obd cluster upgrade 失败，提示：No such package oceanbase-ce-4.2.1.11
但是实际在运行的 observer 是 4.2.1.10，不知道这个 4.2.1.11 是从哪里来的。

image
image882×291 10.8 KB

image
image2049×301 12.5 KB

【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

1 个赞
#4

image
image807×155 22.9 KB

1 个赞
#6

根据您提供的信息，以下是关于通过 obd 升级 oceanbase-ce 失败问题的分析和解决建议：

问题分析

  1. 错误提示
    您在执行 obd cluster upgrade 命令时，遇到了以下错误：

    No such package oceanbase-ce-4.2.1.11

    这表明 obd 在尝试升级时，寻找的是版本 4.2.1.11 的包，但实际运行的 observer 是 4.2.1.10。

  2. 可能原因

    • 默认升级策略：obd 默认会尝试升级到最新稳定版本。如果 4.2.1.11 是当前官方仓库中的最新版本，而您的集群运行的是 4.2.1.10，obd 会自动选择升级到 4.2.1.11。
    • 本地镜像或仓库问题：如果您的环境中没有正确配置 obd 的软件包仓库，或者本地镜像中缺少 4.2.1.11 的包，会导致该错误。
    • 版本不匹配：确保 obd 和 oceanbase-ce 的版本兼容。例如，obd 版本 2.10.1 是否支持 oceanbase-ce 的 4.2.x 系列。

  3. OCR 提取内容验证

    • 第一张图片显示了 obd cluster upgrade 的命令输出，确认了 obd 尝试升级到 4.2.1.11。
    • 第二张图片显示了当前集群的状态，observer 的版本为 4.2.1.10。

解决方案

方法 1：指定目标版本进行升级

如果您希望将集群从 4.2.1.10 升级到特定版本（如 4.2.1.11），可以使用以下命令：

obd cluster upgrade <cluster_name> --target_version=4.2.1.11

如果目标版本不存在，请检查 obd 的软件包仓库是否包含该版本。

方法 2：强制升级到当前运行版本

如果您不希望升级到更高版本，而是重新部署当前版本（4.2.1.10），可以使用以下命令：

obd cluster upgrade <cluster_name> --target_version=4.2.1.10

方法 3：检查并更新 obd 的软件包仓库

  1. 查看当前仓库配置
    执行以下命令，检查 obd 的软件包仓库配置：

    obd mirror list

    如果未找到 4.2.1.11 的包，可能是仓库未同步最新版本。

  2. 添加或更新仓库
    如果需要手动添加或更新仓库，可以执行以下命令：

    obd mirror add https://mirrors.oceanbase.com/repo/ce

  3. 验证仓库内容
    使用以下命令验证仓库中是否存在目标版本：

    obd mirror show oceanbase-ce

方法 4：降级 obd 或调整兼容性

如果 obd 的版本与 oceanbase-ce 不兼容，可以尝试降级 obd 到支持 4.2.x 系列的版本。例如：

pip install obd==<compatible_version>

其他建议

  1. 检查日志
    使用 obd 提供的日志功能，进一步排查问题：

    obd log <cluster_name>

  2. 联系技术支持
    如果上述方法无法解决问题，建议使用 obdiag 收集诊断信息，并联系 OceanBase 技术支持团队：

    obdiag collect all -c <cluster_name>

  3. 参考官方文档
    查阅 OceanBase 官方文档 中关于 obd 和升级的相关章节，确保操作符合最佳实践。

总结

根据您的描述，问题的核心在于 obd 默认尝试升级到 4.2.1.11，但该版本在您的环境中不可用。建议按照上述方法逐一排查，并根据实际需求选择合适的解决方案。如果仍有疑问，请提供更多日志信息以便进一步分析。

更多信息请查看:

  1. 使用命令行部署 OCP Express
  2. RANDSTR
  3. UUID_TO_BIN
1 个赞
#7

没有通过 obd，通过 rpm 安装的方式，手动升级成功了。不知道有没有隐患。
升级步骤如下：
1、alter system stop “172.10.0.3:2882”
2、移动原安装目录：mv /data/oceanbase/observer /data/oceanbase/observer_4.2.1.10
3、安装新的 rpm 包：rpm -ivh --prefix /data/oceanbase/observer
4、复制原安装目录中的配置文件：cp /data/oceanbase/observer_4.2.1.10/etc/observer.config.bin /data/oceanbase/observer/etc
5、启动新的 observer
6、alter system start “172.10.0.3:2882”

三台全部升级完成后，通过 dba_ob_servers 查看版本是正确的，但是通过 select version() 查看，仍然是 4.2.1.10
但是今天查看，发现 select version() 也显示 4.2.5.3 了

1 个赞
#8

根据您提供的信息，以下是关于通过 rpm 手动升级 OceanBase 数据库后可能存在的隐患及分析：

问题分析

  1. 升级步骤回顾
    您通过以下步骤完成了手动升级：

    • 停止指定的 observer 实例。
    • 移动原安装目录并安装新的 RPM 包。
    • 复制原配置文件到新安装目录。
    • 启动新的 observer 实例。
    • 验证版本。

  2. 版本检查结果

    • 升级完成后，通过 dba_ob_servers 表查看版本是正确的（4.2.5.3）。
    • 初始时，SELECT VERSION() 返回的是旧版本（4.2.1.10），但后来发现返回了新版本（4.2.5.3）。

  3. 潜在问题

    • SELECT VERSION() 的延迟更新：在某些情况下，SELECT VERSION() 可能会缓存旧版本信息，导致显示不一致。这通常是由于系统元数据未及时刷新所致。
    • 配置文件一致性：虽然您复制了原配置文件，但新版本可能引入了新的配置项或默认值，可能导致配置不完全一致。
    • 数据兼容性：如果新版本对底层存储格式或元数据结构进行了修改，可能会导致数据读写异常。
    • 集群状态同步：手动升级可能导致集群中各节点的状态不同步，影响高可用性和性能。

潜在隐患及解决建议

1. 版本信息不一致

  • 原因：SELECT VERSION() 和 dba_ob_servers 表的版本信息来源不同。前者通常反映当前进程的版本，后者反映集群元数据中的版本。
  • 解决方法：
    • 确保所有节点均已正确升级，并通过以下命令验证：
      SELECT * FROM DBA_OB_SERVERS;
    • 如果仍有不一致，可以尝试重启整个集群以确保元数据同步。

2. 配置文件问题

  • 原因：新版本可能引入了新的配置项或更改了默认值，而您仅复制了旧配置文件，可能导致配置不完整或不正确。
  • 解决方法：
    • 对比新旧版本的默认配置文件，确保所有必要的配置项均已设置。例如：
      diff /data/oceanbase/observer_4.2.1.10/etc/observer.config.bin /data/oceanbase/observer/etc/observer.config.bin
    • 根据新版本的官方文档调整配置文件。

3. 数据兼容性问题

  • 原因：新版本可能对底层存储格式或元数据结构进行了修改，而手动升级未执行必要的迁移或初始化操作。
  • 解决方法：
    • 检查是否有任何错误日志或警告信息，特别是在启动新版本时。
    • 如果发现问题，可以参考 OceanBase 官方文档 中关于升级的数据兼容性章节，确保所有必要步骤均已执行。

4. 集群状态同步

  • 原因：手动升级可能导致集群中各节点的状态不同步，影响高可用性和性能。
  • 解决方法：
    • 确保所有节点均已正确升级，并通过以下命令验证集群状态：
      SHOW FULL PROCESSLIST;
    • 如果发现异常，可以尝试重启整个集群以确保状态同步。

5. 监控和告警

  • 原因：手动升级可能导致监控和告警配置失效。
  • 解决方法：
    • 检查监控工具（如 OCP 或 Prometheus）是否正常工作。
    • 如果发现问题，重新配置监控和告警规则。

总结

通过 rpm 手动升级 OceanBase 数据库虽然成功，但仍可能存在以下隐患：

  • 版本信息不一致。
  • 配置文件不完整或不正确。
  • 数据兼容性问题。
  • 集群状态不同步。
  • 监控和告警配置失效。

建议按照上述方法逐一排查并解决潜在问题。同时，为了避免类似问题，建议在未来升级时优先使用 obd 工具，以确保升级过程的安全性和一致性。如果仍有疑问，请提供更多日志信息以便进一步分析。

具体信息可参考以下文档:

  1. 使用 obd 进行运维
  2. 升级 OBShell
  3. OBCDC 支持增量旁路导入
  4. 升级 OceanBase 集群
  5. 使用命令行部署 OceanBase 数据库生产环境
  6. ob_error
  7. 在 Kubernetes 环境中部署 OceanBase 集群

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

1 个赞
#9

看不透问题的方向

#10

你好，这种升级方式无法确保其后续可正常运行。