Root Service 问题

Root Service 服务在部署时,是否需要在每个节点上都部署?日常运行时,Root Service会运行在每个节点吗?还是跟集群的primaryzone的顺序是一致的呢?

@论坛小助手

根据文档库中的信息,Root Service 服务在部署和运行时的行为如下:

  1. 部署时是否需要在每个节点上都部署

    • Root Service 的各个副本并不是单独的进程,而是某些节点上启动的一个服务。因此,在部署时,并不需要在每个节点上都部署 Root Service 服务。具体来说,可以通过集群配置指定 Root Service 服务的副本数,这些副本会分布在不同的节点上(依据片段标题:节点故障的自动处理 → Root Service 高可用)。
  2. 日常运行时是否运行在每个节点上

    • 在日常运行时,Root Service 并不会运行在每个节点上。Root Service 的各副本基于 Paxos 协议选举出一个 Leader,只有这个 Leader 副本会为集群提供 Root Service 服务(依据片段标题:节点故障的自动处理 → Root Service 高可用)。
  3. 与集群 Primary Zone 的顺序关系

    • Root Service 的 Leader 选举并不直接依赖于集群的 Primary Zone 的顺序。Leader 的选举是通过 Paxos 协议完成的,这意味着哪个副本成为 Leader 是由协议决定的,而不是简单地按照 Primary Zone 的顺序来确定。不过,在进行数据均衡时,Root Service 会考虑租户的 Primary Zone 等因素,以优化 Leader 的分布(依据片段标题:日志流和副本概述 → 数据均衡)。

总结来说,Root Service 不需要在每个节点上都部署,日常运行时也只会在选举出的 Leader 节点上提供服务,其 Leader 的选举过程独立于 Primary Zone 的顺序,但数据均衡时会考虑 Primary Zone 的设置。

详情请参考:

  1. 节点故障的自动处理
  2. 日志流和副本概述
  3. 集群架构
  4. 使用命令行进行运维
  5. SYS 租户/RS 服务问题
  6. 通过 OMS 进行数据迁移和同步
  7. 备份架构
  8. OceanBase 集群高可用部署方案简介
1 个赞

Root Service 的 Leader 选举 是如何进行和完成的呢 @论坛小助手

学习了

根据文档库中的信息,Root Service 的 Leader 选举过程如下:

1. 选举协议基础

Root Service 的高可用性是通过 Paxos 协议实现的。Root Service 的多个副本分布在不同的节点上,这些副本通过 Paxos 协议选举出一个 Leader 副本(依据片段标题:节点故障的自动处理 → Root Service 高可用)。

2. 选举流程

  • 初始化阶段:在集群启动时,Root Service 的各个副本会进入初始化状态,准备参与选举。
  • 预投票阶段:每个副本会广播自己的提议版本号,尝试获取其他副本的认可。
  • 投票阶段:副本之间进行投票,只有获得多数派支持的副本才能成为候选 Leader。
  • 计票与确认阶段:一旦某个副本获得了多数派的支持,它将被确认为新的 Leader,并开始提供服务。
  • 租约机制:选举成功后,Leader 会签订一个租约(Lease),在租约有效期内,其他副本不会发起新的选举。Leader 定期发起连任请求以延长租约(依据片段标题:集群管理 FAQ → 选举 FAQ → OceanBase 集群的选举模块是如何保证 RTO 不大于 8s 的?)。

3. 特殊场景下的选举

  • 无主选举:当当前 Leader 故障或无法连任时,其他副本会在租约到期后发起无主选举,重新选出一个新的 Leader。这个过程通常在 4 秒内完成(依据片段标题:集群管理 FAQ → 选举 FAQ → OceanBase 集群的选举模块是如何保证 RTO 不大于 8s 的?)。
  • 有主改选(切主):如果当前 Leader 在续约过程中发现某个 Follower 的优先级更高,则会主动触发切主流程,将 Leader 角色让给更优的副本(依据片段标题:集群管理 FAQ → 选举 FAQ → OceanBase 集群的选举有哪几种,分别是由谁发起的?)。

4. 选举优先级

在选举过程中,OceanBase 数据库会综合考虑以下因素来决定哪个副本更适合成为 Leader:

  • 健康状况:优先选择健康状况更好的副本。
  • 成员列表版本号:版本号较高的副本具有更高的优先级。
  • 日志同步状况:优先选择日志同步最新的副本(依据片段标题:集群管理 FAQ → 选举 FAQ → 在选举中哪个副本会被选为主,如何保证选举到的 Leader 副本是更好的选择?)。

5. 脑裂问题的避免

通过 Paxos 协议中的多数派共识机制,OceanBase 数据库确保了在任何时刻只有一个 Leader 提供服务,从而彻底避免了脑裂问题(依据片段标题:高可用 FAQ → OceanBase 数据库选举如何避免脑裂问题?)。

总结

Root Service 的 Leader 选举是基于 Paxos 协议完成的,整个过程包括预投票、投票、计票和确认等多个阶段。选举完成后,Leader 会签订租约以确保其在一定时间内唯一性。如果 Leader 故障或需要切换,系统会通过无主选举或有主改选的方式快速选出新的 Leader,同时通过多数派共识机制避免脑裂问题的发生。

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

  1. 选举
  2. 高可用 FAQ
  3. 节点故障的自动处理
  4. 集群管理 FAQ
  5. 日志流和副本概述
  6. Paxos 协议
  7. 使用命令行进行运维
1 个赞

如何查看集群中Root Service 服务的分布,状态等信息呢? @论坛小助手

根据文档库中的信息,您可以使用以下方法查看集群中 Root Service 服务的分布和状态等信息:

  1. 查看 Root Service 主节点

要获取当前 Root Service 的主节点(即 Leader)所在的 IP 地址,可以执行以下 SQL 查询(依据片段标题:使用命令行进行运维 → 常用 SQL → 集群基础 SQL → 查看 Root Service 主节点):

SELECT svr_ip as RootService FROM oceanbase.DBA_OB_SERVERS WHERE with_rootserver='yes';

这条 SQL 语句会从 oceanbase.DBA_OB_SERVERS 系统视图中筛选出带有 Root Service 的服务器,并返回其 IP 地址。

  1. 查看近期集群事件

为了了解 Root Service 在集群中的活动情况,包括但不限于节点故障、拉黑、永久下线节点、迁移 Unit 等事件,可以查询 oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY 视图。这有助于分析 Root Service 的调度行为和集群运行稳定性(依据片段标题:如何查看集群近期 1 小时内发生的事件):

SELECT `TIMESTAMP`,module,EVENT,name1,value1,name2,value2,rs_svr_ip 
FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY 
WHERE module IN ( 'server', 'root_service', 'balancer' ) AND `TIMESTAMP` > SUBDATE( now(), INTERVAL 1 HOUR ) 
ORDER BY `TIMESTAMP` DESC LIMIT 50;

此查询将返回过去一小时内与 Root Service 相关的事件记录,按时间倒序排列并限制结果数量为 50 条。

  1. 使用 obshell-sdk-go 或 obshell-sdk-python 查询集群信息

如果您希望通过编程方式获取更详细的集群信息,包括 Root Service 的状态,可以使用 obshell-sdk-goobshell-sdk-python。下面分别给出两种语言的示例代码(依据片段标题:查询集群信息)。

  • 使用 obshell-sdk-go:

首先创建一个 client 实例连接到 OceanBase 集群,然后调用相关 API 获取集群详细信息:

package main

import (
"fmt"

"github.com/oceanbase/obshell-sdk-go/services"
)

func main() {
// 创建 client 实例,节点地址为 '10.10.10.1',端口为 2886。
// 所在集群的 root@sys 密码为 '****'。
client, err := services.NewClientWithPassword("10.10.10.1", 2886, "***")
if err != nil {
panic(err)
}

// 获取 OceanBase 集群的详细信息。
obInfo, err := client.V1().GetObInfo()
if err != nil {
panic(err)
}
fmt.Print(obInfo)
}
  • 使用 obshell-sdk-python:

类似地,在 Python 中也可以通过 obshell-sdk-python 获取集群信息:

from obshell_sdk_python.services import Client

# 创建 client 实例,节点地址为 '10.10.10.1',端口为 2886。
# 所在集群的 root@sys 密码为 '****'。
client = Client("10.10.10.1", 2886, "***")

# 获取 OceanBase 集群的详细信息。
ob_info = client.v1().get_ob_info()
print(ob_info)

以上方法可以帮助您全面了解集群中 Root Service 服务的分布和状态信息。

详情请参考:

  1. 使用命令行进行运维
  2. 集群架构
  3. 日志流和副本概述
  4. 节点故障的自动处理
  5. 查询 OceanBase 集群的最后一个运维任务
  6. 查询集群信息
  7. SYS 租户/RS 服务问题
  8. 集群近期 1 小时内发生的事件

with_rootserver=‘no’ ,是表示从副本还是未部署Root Service 服务呢? @论坛小助手

根据文档库中的信息,with_rootserver='no' 表示该服务器未部署 Root Service 服务。

在系统视图 oceanbase.DBA_OB_SERVERS 中,字段 with_rootserver 用于标识某台服务器是否运行有 Root Service 服务。具体来说:

  • with_rootserver='yes' 时,表示该服务器上部署并运行有 Root Service 服务(可能是 Leader 或 Follower 副本)。
  • with_rootserver='no' 时,表示该服务器上未部署 Root Service 服务(依据片段标题:使用命令行进行运维 → 常用 SQL → 集群基础 SQL → 查看 Root Service 主节点)。

因此,with_rootserver='no' 并不是指从副本,而是明确指出该服务器没有部署 Root Service 服务。如果需要了解某个服务器上的 Root Service 副本角色(Leader 或 Follower),则需要进一步查询其他相关信息或日志。

详情请参考:

  1. 日志流和副本概述
  2. 使用命令行进行运维
  3. 集群架构
  4. 4500 ~ 4999
  5. 节点故障的自动处理
  6. 重启节点
1 个赞

如何查询哪些是Root Service 服务的主副本和从副本呢? @论坛小助手

根据文档库中的信息,查询 Root Service 服务的主副本(Leader)和从副本(Follower)可以通过以下方法实现:

查询 Root Service 主副本(Leader)

要获取当前 Root Service 的主副本(Leader)所在的服务器 IP 地址,可以执行以下 SQL 查询(依据片段标题:使用命令行进行运维 → 常用 SQL → 集群基础 SQL → 查看 Root Service 主节点):

SELECT svr_ip AS RootServiceLeader 
FROM oceanbase.DBA_OB_SERVERS 
WHERE with_rootserver='yes';

这条 SQL 语句会从 oceanbase.DBA_OB_SERVERS 系统视图中筛选出带有 Root Service 的服务器,并返回其 IP 地址。需要注意的是,虽然此查询可以找到所有运行 Root Service 的服务器,但只有其中一个为 Leader。

为了进一步确认哪个是 Leader,可以结合日志或通过其他管理工具如 OCP 来查看具体的 Leader 信息。

查询 Root Service 从副本(Follower)

Root Service 的从副本(Follower)信息并不直接暴露在系统视图中,但可以通过间接方式推断出来。由于 Root Service 使用 Paxos 协议实现高可用性,且 Leader 是从多个副本中选举出来的,因此除了 Leader 之外的其他副本即为 Follower。

可以通过以下步骤来确定 Follower:

  1. 列出所有 Root Service 副本所在的服务器
    使用以下 SQL 查询列出所有运行 Root Service 的服务器:

    SELECT svr_ip AS RootServiceReplica 
    FROM oceanbase.DBA_OB_SERVERS 
    WHERE with_rootserver='yes';
    

    这将返回所有运行 Root Service 的服务器列表,包括 Leader 和 Follower。

  2. 排除 Leader
    根据第一步查询到的所有 Root Service 副本所在的服务器,结合前面查询到的 Leader 所在的服务器 IP 地址,剩下的服务器即为 Follower。

使用 OCP 或其他管理工具

除了通过 SQL 查询外,还可以使用 OceanBase 提供的图形化管理平台 OCP 或命令行工具 obd 来查看 Root Service 的 Leader 和 Follower 信息。这些工具通常会提供更直观的界面展示集群状态,包括 Root Service 的分布和角色信息。

总结

  • 使用 SQL 查询可以从系统视图中获取 Root Service 的主副本(Leader)和所有副本所在的服务器。
  • 通过排除法可以确定哪些是 Follower。
  • 推荐使用 OCP 或其他管理工具以获得更直观的信息展示。

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

  1. 使用命令行进行运维
  2. 日志流和副本概述
  3. 节点故障的自动处理
  4. 集群架构
  5. rootservice_list
  6. OceanBase 数据库整体架构
  7. 4500 ~ 4999
  8. oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY
1 个赞

RS节点就是SYS租户所在的节点,DBA_OBSERVERS中的 WITH_ROOTSERVER是YES就是RS节点的主节点,对应的就是主副本

1 个赞