OB的探活原理是什么？

OceanBase 技术问题
#1

关于OB的主库探活原理，有大佬知道它是只探select操作吗？还是update/delete/insert也会探？主库变只读的场景能否发现然后触发自动切换？

3 个赞
#3

Failover自动切换？？？？？？？

2 个赞
#4

这个是哪一部分的概念啊

2 个赞
#5

@论坛小助手

1 个赞
#6

OceanBase (OB) 的探活机制主要包括以下几个方面：

  1. 定时任务：定期刷新节点、Zone、主备集群状态。
  2. Server 连接保持与 KeepAlive 探活机制：用于探测 ODP (OceanBase Proxy) 与后端节点的连接状况，如果空闲连接异常断开，obproxy 可以及时发现，剔除并新建连接。
  3. Client KeepAlive 探活机制：用于探测 obproxy 与客户端的连接状况，同时可以避免 SLB 等负载均衡设备的空闲超时问题。

这些探活机制不仅限于 SELECT 操作，还包括 UPDATE、DELETE 和 INSERT 等所有类型的 SQL 操作。只要后端节点的连接出现异常，探活机制会立即检测到并采取相应措施。

对于主库变只读的场景，探活机制同样适用。一旦检测到主库变为只读状态，OB 会触发自动切换，确保系统的高可用性。

检索到的文档如下:

  1. 代理高可用
1 个赞
#7

OceanBase 主库探活的核心机制

OceanBase 的高可用和故障切换依赖于 Paxos 协议 和 RootService (RS) 的协同工作。探活是其中的关键环节。

1. Paxos 层心跳（最核心的探活）

这是最底层、最可靠的探活机制。

  • 机制：每个副本（Replica）会定期向 Paxos Group 的其他副本发送心跳消息（Heartbeat）。
  • 内容：心跳不仅仅是“我还活着”，它还包含了副本的状态信息、日志流（Log Stream）的进度、以及对 Paxos 提案的响应能力。
  • 作用：
    • 检测副本是否进程存活、网络可达。
    • 更重要的是，检测副本是否能正常参与 Paxos 投票。如果一个 Leader 无法响应心跳或无法对新的日志提案进行投票（例如，因为内部卡死或无法写入 clog），它就会被 Paxos 组内的多数派（Quorum）判定为“失联”或“不可用”。
  • 与读写的关系：虽然心跳本身不是 SQL，但它要求 Leader 具备处理日志写入（即 INSERT/UPDATE/DELETE 产生的日志）的能力。如果主库因磁盘满等原因无法写入 clog，它将无法推进日志流，从而无法响应心跳或投票，最终被 Paxos 机制淘汰。

2. SQL 层健康检查（辅助探活）

除了 Paxos 心跳，OceanBase 也会通过 SQL 请求来验证服务的健康度，这通常由 RootService 或 负载均衡器（OBProxy） 发起。

  • 机制：
    • 简单探测：可能会定期发送一个轻量级的 SQL，如 SELECT 1; 或 SELECT SYSDATE;，来验证 SQL 引擎是否能响应。
    • 写入探测：在某些配置或场景下，也可能发起一个小的、无害的写入操作（例如，更新一个系统心跳表或特定的探活表）来验证主库的写入通道是否通畅。
  • 目的：这可以更快地发现 SQL 层的故障，比如 SQL 引擎卡死、内存耗尽等，而这些故障可能不会立即影响底层 Paxos 心跳（尽管最终会）。

3. RootService 监控与决策

  • RootService 是 OceanBase 集群的“大脑”，它负责全局调度、DDL、以及高可用切换。
  • 它会综合 Paxos 投票状态 和 SQL 探活结果 来判断 Leader 的健康状况。
  • 如果 RootService 发现当前 Leader 在 Paxos 组内失去了多数派的响应（或投票失败），或者连续多次 SQL 探活（尤其是写入探活）超时失败，它就会认为 Leader 已经不可用。

主库变只读的场景分析

当主库因以下原因变为“只读”时：

  • 磁盘空间耗尽：无法写入 clog 或 SSTable。
  • 内存耗尽：无法分配事务或日志缓冲区。
  • 内部状态异常：如转储或合并卡死，导致写入阻塞。

检测与切换过程：

  1. Paxos 层首先感知：主库无法写入 clog，导致无法生成新的日志条目或无法对新的日志提案进行持久化确认。这会使其在 Paxos 投票中失败或超时。
  2. 心跳超时：主库无法及时响应 Paxos 心跳。
  3. Paxos 触发选举：当多数派副本在一段时间内无法收到 Leader 的有效心跳或投票响应时，Paxos 协议会自动触发重新选举（Re-election）。
  4. 新 Leader 产生：其他健康的副本（通常是 Follower）会发起选举，并在获得多数派投票后成为新的 Leader。
  5. RootService 更新路由：RootService 检测到新的 Leader 产生，会更新集群的路由表，将后续的写请求导向新的主库。
  6. 应用无感知切换：OBProxy 或客户端收到新的路由信息后，会自动将写请求发送到新主库，实现故障切换。

结论

  • OceanBase 的主库探活不局限于 SELECT，其核心是基于 Paxos 协议的心跳和投票机制，这天然地要求主库具备完整的写入和日志处理能力。
  • SQL 层的探活（可能包含写入操作）作为辅助手段，可以更早地发现应用层的故障。
  • 当主库因任何原因（包括变只读）导致无法正常参与 Paxos 协议（无法投票、无法写入日志） 时，Paxos 机制会自动检测到故障并触发选举，从而实现自动切换，保证了系统的高可用性。
2 个赞