故障恢复流程疑问？

OceanBase 技术问题
,
#1

【 使用环境 】测试环境
【 OB or 其他组件 】observer v4.2.4, oboperator v2.3.1
【 使用版本 】observer v4.2.4, oboperator v2.3.1
【问题描述】在k8s上部署了一个三节点集群（包括obproxy）， 使用的租户 Primary Zone设置为random，运行tpc-c负载， 在tpc-c运行过， 先其中一个节点注入节点失效（相当于kill pod一次，后续由operator负责拉起）， 从事务记录中可以看到短暂的qps掉为0。
分析了一下每个线程的情况， 总共32线程， 基本是在18:33:00.91这个时间断开jdbc连接， 然后不同线程从断开连接到故障后成功执行第一条事务时间存在一些差异， 主要其中21个线程在18:33:04.80 （± 10ms）结束故障后第一条成功事务， 另外11个线程则要到18:33:07.15（± 10ms）， 前者4s和后者6s多的时间差异比较大， 是不是因为不同线程事务涉及到了不同parition的， 不同的parition恢复时间不同呢？（差异还是有些大）
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

@论坛小助手

1 个赞
#3

根据文档库中的信息，可以对您的问题进行如下解析：

  1. 关于节点故障恢复机制：

    • 根据文档片段 5，节点失活后 ob-operator 会自动检测到该情况，并且创建出新的 Pod 作为“新节点”加入到原来的集群当中。加入集群之后新节点会向原有节点同步数据，直到所有数据同步完成。需要注意的是，在恢复过程中如果多数派失活，那么集群将无法恢复。如果出现这种情况，需要从备份中手动恢复数据。
    • 文档片段 2 提到，在 OceanBase 4.2.3.0 版本之前内核无法采用虚拟 IP 进行通信，当 Pod IP 发生变化时 observer 将无法正常启动，需要采用某种方式将节点的 IP 固定住才能够让 observer 失活后原地重启。否则只能依赖多数派存活的条件将新的 Pod 以新的节点的方式加入集群并同步数据来恢复原来的节点数量。由于您使用的是 observer v4.2.4，理论上已经解决了这个问题，因此节点故障恢复应该更加顺畅。

  2. 关于 QPS 短暂掉为 0 的现象：

    • 当一个节点失效时，集群会暂时失去该节点提供的服务，这会导致 QPS 短暂下降至 0。这是因为集群需要时间来检测节点失效，并由 ob-operator 创建新的 Pod 来恢复服务。在这个过程中，部分请求可能会失败或超时，导致 QPS 下降。

  3. 关于不同线程恢复时间差异：

    • 您提到的不同线程恢复时间存在差异，可能是由于以下几个原因：
      • 分区恢复时间不同：不同的分区可能分布在不同的节点上，当一个节点失效时，涉及到该节点分区的请求会受到影响。新节点加入集群后，需要同步这些分区的数据，不同分区的数据量和同步速度可能不同，导致恢复时间存在差异。
      • 网络延迟：新节点加入集群后，需要与其他节点进行通信以同步数据。网络延迟可能会影响同步速度，从而导致恢复时间的差异。
      • 资源竞争：在新节点加入集群并开始同步数据的过程中，可能会与其他正在运行的节点争夺资源（如 CPU、内存等），这也可能导致恢复时间的差异。

  4. 建议的进一步诊断步骤：

    • 检查日志：使用 obdiag 收集诊断信息，特别是关注节点失效和恢复期间的日志，查看是否有明显的错误或警告信息。
    • 监控指标：查看集群的监控指标，特别是与网络、CPU、内存相关的指标，了解在节点失效和恢复期间是否存在资源瓶颈。
    • 分区分布：检查各个分区的分布情况，了解哪些分区分布在失效的节点上，以及这些分区的数据量和同步速度。

综上所述，不同线程恢复时间的差异可能是由于分区恢复时间不同、网络延迟和资源竞争等因素造成的。建议您通过检查日志和监控指标来进一步诊断具体原因。

更多信息请查看:

  1. 故障恢复
  2. 高可用
  3. 从 Zone 中减少 OBServer 节点
  4. 数据库应急概述
  5. OceanBase 集群高可用部署方案简介
  6. 节点宕机
  7. OceanBase 数据库社区版 V3.1.2
  8. 集群管理 FAQ
  9. OceanBase 数据库社区版 V4.2.0
1 个赞
#4

来学习一下

#5

小助手的回复已经很不错了，分区恢复时间不同，涉及到需要同步到离线期间到增量数据到表中，这个量是不一致的。
还有部分sql涉及的表可能存在主副本不在故障节点中。