断电重启后 3副本里面有一个zone的节点用ocp启动失败，急急急

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】断电重启后 3副本里面有一个zone的节点用ocp启动失败，急急急；
具体报错信息和日志：
{“successful”:false,“timestamp”:“2025-05-29T13:46:44.5529234+08:00”,“duration”:0,“status”:401,“traceId”:"",“server”:"",“error”:{“code”:1101,“message”:“Authentication failed for invalid header authorization”,“detail”:null}}

日志文件：subtask_5000057.log (41.8 KB)

请各位大神帮忙看下原因和解决方案，急急急

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

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

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

#3

日志采集场景: 集群无法连接
日志采集命令: obdiag gather scene run --scene=observer.cluster_down

推荐使用 obdiag 工具进行日志采集，并且将采集到的日志提供给我们以便确认问题所在。上述命令会收集与集群启动失败相关的日志和信息，帮助我们分析为什么该 zone 的节点在断电重启后通过 OCP 启动失败。

另外，为了确定具体的问题，在此需要您提供一些信息：

  1. 断电之前是否有对 OceanBase 集群进行过任何配置变更或维护操作？如果有，请详细描述变更内容。
  2. 该 zone 的节点是否曾经成功通过 OCP 启动过？如果是，请说明最近一次成功启动的时间。
  3. 是否检查过节点的权限配置或认证信息（如 header authorization）是否有异常？如果有，请提供相关检查结果。
  4. 除了错误代码 4013 和 ‘Authentication failed for invalid header authorization’，日志中是否还有其他异常信息或报错？如果有，请一并提供。
  5. 当前集群的部署模式是通过 OCP、OBD 还是手工部署的？

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

#4

obdiag gather scene run --scene=observer.cluster_down

这个是放在ob节点吗

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

#5

根据您的问题，obdiag gather scene run --scene=observer.cluster_down 命令是用来收集 OceanBase 集群在启动失败或连接异常时的相关日志和诊断信息的。此命令需要在可以访问目标 OB 节点的机器上执行，通常是在 OB 集群节点所在的服务器或者管理节点上运行。

以下是具体的操作步骤：

  1. 登录到管理节点或目标 OB 节点：确保您有权限访问这些节点，并且 obdiag 工具已正确安装。

  2. 执行 obdiag 命令：

    obdiag gather scene run --scene=observer.cluster_down

    此命令会自动收集与当前问题相关的日志、配置文件和其他诊断信息。

  3. 检查输出结果：执行完上述命令后，会在指定目录下生成一个压缩包，里面包含了所有采集到的日志和信息。您可以将这个压缩包上传或者分享给我们以进一步分析问题。

  4. 注意事项：

    • 确保 obdiag 工具版本是最新的，以便支持最新的诊断场景。
    • 如果您不确定在哪台机器上运行该命令，建议在 OCP 管控平台上查看目标 zone 的节点信息，并选择其中一台代表性的节点来运行此命令。

通过以上步骤，您可以有效地收集到所需的诊断信息，帮助我们更快地定位和解决问题。如果还有其他疑问，请随时告知！

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

  1. 离线分析日志文件夹
  2. 执行 sysbench 时的巡检任务集合
  3. 停止 OceanBase 集群
  4. 监控告警
  5. 执行 sysbench 前的巡检任务集合
  6. 通过 obdiag 工具进行诊断和分析
#6

检查下主机密码和ocp_agent状态

#7

这些都没动过

#8

POST request to agent, url:http://172.17.2.98:62888/api/v1/process/info
看日志 是在频繁像agent发送请求失败，看一下98节点主机状态agent是否正常

1 个赞
#9

根据您的回复“这些都没动过”，可以理解为断电之前没有对 OceanBase 集群进行任何配置变更或维护操作。那么接下来我们可以从以下几个方面来排查问题：

1. 权限与认证信息

错误日志中提到 Authentication failed for invalid header authorization，这表明 OCP 在尝试启动 OB 节点时遇到了权限认证失败的问题。请检查以下内容：

  • OCP Agent 的认证信息：确保 OCP 和目标节点上的 OCP Agent 的认证信息一致，包括 token、密钥等。
  • 用户权限：确认用于启动 OB 节点的用户（如日志中的 admin 用户）是否具有足够的权限。

2. 日志分析

通过 obdiag gather scene run --scene=observer.cluster_down 收集的日志可以帮助我们进一步分析问题。重点检查以下日志文件：

  • observer.log：查看 OB Server 的启动日志，寻找是否有启动失败的具体原因。
  • rootservice.log：如果存在角色切换或者选举问题，rootservice.log 中会有相关记录。
  • ocp-agent.log：检查 OCP Agent 的日志，确认是否有异常或错误信息。

3. 网络与服务状态

  • 网络连通性：确保 OCP 和目标 OB 节点之间的网络是通畅的，没有防火墙或其他网络设备阻止通信。
  • 服务状态：确认目标节点上的 OCP Agent 和 OB Server 是否正常运行。可以通过以下命令检查：
    ps -ef | grep ocp-agent
ps -ef | grep observer

4. 配置文件检查

  • OB 配置文件：检查 OB Server 的配置文件（通常位于 /home/admin/oceanbase/etc/observer.config.ini），确保配置项正确无误。
  • OCP 配置：在 OCP 管控平台上，检查该 zone 的配置是否正确，特别是与认证和网络相关的配置。

5. 重新启动尝试

如果以上检查均未发现问题，可以尝试手动重启 OCP Agent 和 OB Server：

# 停止 OCP Agent
ocp-agent stop

# 启动 OCP Agent
ocp-agent start

# 手动启动 OB Server
/home/admin/oceanbase/bin/observer -c /home/admin/oceanbase/etc/observer.config.ini

6. 联系支持

如果经过以上步骤仍然无法解决问题，建议联系 OceanBase 的技术支持团队，提供详细的日志和配置信息以便进一步分析。

希望以上建议能够帮助您解决问题！如果有任何进展或新的发现，请随时更新信息。

详情请参考:

  1. innodb_stats_persistent
  2. enable_separate_sys_clog
  3. ACTIVATE STANDBY
  4. 查询所有未完成的任务
  5. 无主
  6. 查询 Agent 未完成的任务
  7. plan_cache_low_watermark

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

#10

确实是重装ocp agant好了，这个问题发生的大概原因是什么？

#11

可能就是节点重启后agent自启动服务启动异常导致

#12

agent有时候运行运行着就不采集监控数据了，进程都显示正常，都得要重装一下才好 :rofl:

#13

是不是agent内存超限导致的agent进程中断了，可以扩容内存看看还会出问题么

#14

就是扩到6g后才出现的这个问题，重装有时候也失败，可能和改了内存有关系，没改的agent没啥事 :joy:

#15

厉害，解决了，重装ocp agent