【 使用环境 】测试环境
【 使用版本 】v4.3.2
【问题描述】目前在做版本升级以及高可用相关的测试，对 OB 切主的时机有一些疑问：
-
根据文档的描述 RS 只是在接收各个 Observer 上报的元信息，在不同的场景下，RS 承担的角色不同？比如磁盘，服务器故障等，根据心跳以及操作系统层面的信息情况来判断是否会主动触发切主，或者补数据副本的操作？官方文档的描述如下：
“OBServer 心跳数据包存在，心跳数据包中的 OBServer 磁盘状态异常。此种状态下，Root Service 认为 observer 进程还在，但 OBServer 磁盘故障。此种状态下，Root Service 会尝试将该 OBServer 上的全部 leader 副本切走”
-
下述场景下的切主由谁触发，RS or 日志流切主？
- compaction
- 集群版本滚动升级过程中
- 调整租户的 primary zone
- 缩容 observer
- 其他非预期故障，均是由选举日志流进行的切主？
另外，可以理解为官网提到的 RTO < 8s 是指一个租户的日志流切换的耗时，当租户的数量比较多，待切主的基数较大时，业务端感知到的单 observer 的 RTO 极有可能是大于 8s 的？
除此之外，有类似 TiDB 调度的 scheduler 相关参数的控制吗？比如对各个调度都有调度速度控制相关的参数，hot region scheduler，region balance scheduler…
或者关于这块有相关的材料可以学习吗？谢谢 ~
1 个赞
旭辉
#4
OceanBase 的 RS（Root Service）组件对切主的管理机制如下：
-
切主的触发条件：切主通常发生在集群启动、Leader 连任失败、手动切主或无主选举等场景下。
-
切主的控制者：切主动作由每个 Paxos 组的 Leader 控制。当 Leader 在续约流程中发现某个 Follower 比它的优先级更高时，它会执行切主流程“让贤”。
-
切主的实现：在 OceanBase 数据库 V4.x 中，切主是日志流维度的。日志流的 Leader 上任取决于选举模块、CLOG 模块和 RoleChangeService 模块三个模块的协作。
-
选举模块：基于 OceanBase 数据库特有的选举算法，产生 Leader 并保证 Leader 的唯一性，称其为 Election Leader。
-
CLOG 模块：基于 Election Leader，先执行 reconfirm 流程，确保 CLOG Leader 具有全量日志。然后执行 CLOG 的上任流程，异步通知 RoleChangeService 模块。
-
RoleChangeService 模块：当感知到 CLOG Leader 需要执行上任流程后，负责执行具体的上任逻辑，使其他模块能够感知并响应 Leader 的切换动作。
这些机制共同确保了 OceanBase 集群在面对节点故障时能够快速有效地进行 Leader 的切换，从而维持系统的高可用性和数据的一致性。
集群管理 FAQ
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001049830
高可用 FAQ
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001573568
SYS 租户/RS 服务问题
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001574360
