ob sys 租户不可用导致集群宕机

OceanBase 技术问题
#1

【 使用环境 】 测试环境
【 OB or 其他组件 】ob
【 使用版本 】4.2.1.10
【问题描述】sys 当前租户不可用
租户状态：不可用 (持续时间：1小时22分钟1秒)
原因：连接 sys 执行 SELECT /*+ query_timeout(60000000) */ TENANT_ID, TENANT_NAME, TENANT_TYPE, PRIMARY_ZONE, LOCALITY, COMPATIBILITY_MODE, STATUS, IN_RECYCLEBIN, (CASE WHEN LOCKED = ‘YES’ THEN 1 ELSE 0 END) AS LOCKED, TIMESTAMPDIFF(SECOND, CREATE_TIME, now()) AS exist_seconds , ARBITRATION_SERVICE_STATUS, REPLACE(SWITCHOVER_STATUS, ’ ', ‘_’) as SWITCHOVER_STATUS, LOG_MODE, SYNC_SCN, RECOVERY_UNTIL_SCN, TENANT_ROLE FROM oceanbase.DBA_OB_TENANTS WHERE TENANT_TYPE IN (‘SYS’, ‘USER’) 失败，错误信息: (conn=3221544589) Timeout, query has reached the maximum query timeout: 60000000(us), maybe you can adjust the session variable ob_query_timeout or query_timeout hint, and try again.
解决方案：请联系技术支持

【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

1 个赞
#3

根因分析场景: 事务执行超时报错
根因分析命令: obdiag rca run --scene=transaction_execute_timeout
日志采集场景: 集群无法连接
日志采集命令: obdiag gather scene run --scene=observer.cluster_down

推荐使用 obdiag 工具进行根因分析和日志采集，以便确认问题所在。上述命令可以帮助您定位导致 sys 租户不可用以及集群宕机的具体原因，并收集相关日志以供进一步分析。

请您按照以下步骤操作：

  1. 执行根因分析命令 obdiag rca run --scene=transaction_execute_timeout，该命令将帮助我们分析事务执行超时的原因。
  2. 执行日志采集命令 obdiag gather scene run --scene=observer.cluster_down，该命令将收集与集群宕机相关的日志信息。

完成上述操作后，请将生成的日志压缩包提供给我们，以便进一步确认问题。

另外，为了更好地帮助您解决问题，请回答以下问题：

  1. sys 租户在什么时间开始变得不可用？是否有特定的操作或事件触发了这一问题？
  2. 在 sys 租户不可用之前，是否执行过大规模的查询或事务操作？如果有，请描述具体的操作内容。
  3. 集群的部署模式是什么（例如通过 OCP、OBD 或手动部署）？
  4. 是否有其他租户也出现了类似的问题？如果有，请说明受影响的租户名称及其状态。
  5. 集群的硬件资源（如 CPU、内存、磁盘空间）是否有异常情况？例如是否有磁盘空间不足或内存占用过高的现象？

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

1 个赞
#4

在10点左右出现问题，当时是没有对集群有过操作

1 个赞
#5

不过sys的其中一个zone 是我业务租户的一个备租户

1 个赞
#6

根据您提供的信息，sys 租户的其中一个 zone 是您业务租户的一个备租户，并且在 10 点左右出现问题时没有对集群进行过操作。以下是可能的原因分析和解决方案：

可能原因分析

  1. 租户无主问题
    根据文档信息，如果 sys 租户的某个 zone 是业务租户的备租户，可能存在以下情况：

  2. CLOG 写盘慢或网络延迟
    如果 sys 租户的 CLOG 写盘性能下降或与 Follower 副本之间的网络延迟增加，也可能导致 Leader 副本无法正常工作。需要检查 CLOG 盘的负载、网络延迟等指标。（参考 片段标题: 无主 → 常见的租户无主的原因 → 事务回调执行异常）

  3. Takeover 失败
    如果 sys 租户的 Leader 副本在 Takeover 状态下未能成功上任，可能是 RoleChangeService 模块工作异常，导致集群无主。（参考 片段标题: 无主 → 常见的租户无主的原因 → Takeover 失败）

  4. 租户队列积压
    如果 sys 租户队列积压，可能会导致其无法正常处理请求，进而影响整个集群的可用性。（参考 片段标题: SYS 租户/RS 服务问题 → 应急处理方法）

解决方案

1. 检查 CLOG 和网络状态

  • 检查 CLOG 写盘性能：查看 sys 租户所在节点的 CLOG 盘负载和 await 指标，确认是否存在写盘慢的问题。
  • 检查网络延迟：确认 sys 租户 Leader 副本与 Follower 副本之间的网络延迟是否正常，排查是否有网络包耗时较大的情况。

2. 检查 Takeover 状态

  • 查看 sys 租户的 Takeover 状态，确认是否存在 RoleChangeService 模块异常的情况。可以通过以下命令检查：
    SHOW PROCESSLIST;
    如果发现有长时间处于 Takeover 状态的任务，可能需要进一步排查 Takeover 失败的原因。

3. 检查队列积压

4. 使用 obdiag 工具收集日志

  • 推荐使用 obdiag 工具收集相关日志，以便进一步分析问题：
    obdiag gather scene run --scene=observer.cluster_down

进一步确认的信息

为了更好地定位问题，请提供以下信息：

  1. 是否可以在 observer.log 中找到类似以下的错误信息：

    check_leader_sliding_window_not_slide_

    如果存在，请提供具体的日志内容。

  2. 集群中其他租户的状态是否正常？是否有类似的不可用现象？

  3. 集群的硬件资源（如 CPU、内存、磁盘空间）是否有异常情况？例如是否有磁盘空间不足或内存占用过高的现象？

通过上述步骤，您可以更全面地了解问题的根本原因，并采取相应的措施解决 sys 租户不可用导致的集群宕机问题。

更多信息请查看:

  1. SYS 租户/RS 服务问题
  2. 分布式事务
  3. 数据库应急概述
  4. 其他问题
  5. 无主
  6. 重置集群配置项
  7. 停止备份

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

1 个赞
#7

1、把observer.log日志发一下 如果是多节点的 多个节点的日志都发一下
2、如果是obd搭建的集群 发一下yaml文件
obd cluster list --查看集群名
obd cluster edit-config {集群名} --保存在文本里 提供一下
3、日志采集场景: 集群无法连接
日志采集命令: obdiag gather scene run --scene=observer.cluster_down
obdiag 使用帮助链接

1 个赞
#8

谢谢了已经恢复了