部署 OB 集群时，Bootstrap ob 报错怎么办？

1. 问题背景

在创建新集群时，经常会卡在步骤 Bootstrap ob。接下来，将详细介绍该步骤的底层处理过程以及可能导致失败的原因。

1.1 底层处理过程

当 OceanBase 集群的三个节点均正常启动，且监听处于正常状态时，可通过 2881 端口直接连接到任意一个节点，执行 bootstrap
 命令完成集群初始化操作，初始密码为空。

以三节点集群为例，执行命令如下：

mysql -h 172.20.249.49 -u root -P 2881 -p -c -A
set session ob_query_timeout=1000000000; 
alter system bootstrap ZONE 'zone1' SERVER '172.20.249.52:2882', ZONE 'zone2' SERVER '172.20.249.49:2882', ZONE 'zone3' SERVER '172.20.249.51:2882' ;

1.2 初始化失败常见原因

• 集群节点之间的时间同步延迟超过 50ms。
• 集群节点之间的网络延迟超过 100ms。
• 集群节点上 OBSERVER 相关目录结构不正确，或者目录权限设置错误。
• 集群节点上 observer
   进程启动参数配置错误，需特别注意参数名称（如 __min_full_resource_pool_memory
  ）、参数 -d
   对应的目录是否正确、参数 -z
   与 IP 的对应关系，以及参数中是否多了空格或分隔符错误（有的应为 ,
  ，有的应为 ;
  ）。
• 集群节点的可用内存小于 observer
   进程启动参数 memory_limit
   所设置的值。

2. 排查过程

按照上述常见原因，依次进行如下排查：

2.1 查看 observer.log 日志

通常情况下，observer.log
 日志会显示启动失败的原因，通过过滤该日志可判断失败根源。

执行命令：

grep "ERROR" observer.log

示例日志输出：

[root@10-186-63-138 log]# grep "ERROR" observer.log
[2025-05-16 11:30:39.452979] ERROR [SERVER] init_config (ob_server.cpp:906) [25581][0][Y0-0000000000000000-0-0] [lt=36] invalid config from cmdline options(opts_.optstr_="obconfig_url=http://10.186.63.19:8080/services?Action=ObRootServiceInfo&User_ID=alibaba&UID=ocpmaster&ObRegion=hwc_test6,rootservice_list=10.186.63.138:2882:2881,config_additional_dir=/data/log1/hwc_test6/etc2;/data/1/hwc_test6/etc3,cluster_id=1746510623,datafile_disk_percentage=20,system_memory=4G,__min_full_resource_pool_memory=1073741824,clog_disk_utilization_threshold=20,clog_disk_usage_limit_percentage=30", ret=-4147) BACKTRACE:0xfc4bc10 0xfc2b64d 0x58371fe 0x5ad1364 0xc096404 0xc08181b 0xc07f562 0x5835654 0x7f676f8af445 0x5834296

根据报错信息 invalid config from cmdline options 可知，是参数设置不合理导致失败。进一步排查发现参数 clog_disk_usage_limit_percentage=30
 存在问题。

查阅官方文档后确认：clog_disk_usage_limit_percentage
 参数不在取值范围之内。删除该参数后重新创建集群任务，创建成功。

若 observer.log
 日志未显示明显错误，可按照以下常见原因继续排查。

2.2 检查时间同步

时间同步通常采用两种方式：chronyc
 和 NTP 同步，可通过以下命令验证时间时效性，若时间不同步，需先校准时间再重新启动。

2.2.1 chronyc 方式

执行命令：

[root@10-186-63-76 ~]# chronyc sources -v
210 Number of sources = 1
  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current synced, '+' = combined , '-' = not combined,
|    '?' = unreachable, 'x' = time may be in error, '~' = time too variable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================================
^* 10.186.63.33                  2   6   377    32  +5249ns[+6011ns] +/-  111ms

手动同步时间：

• root 用户：chronyc makestep
  
• 非 root 用户：chronyc -a makestep
  

时间同步偏差可通过测量偏移量判断，例如上述示例中，当前本地时间比时间源快 6.011 微秒（Last sample 列中 [+6011ns]
 即为测量偏移量）。

2.2.2 NTP 方式

示例输出：

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+time1.aliyun.com  203.107.6.88   2 u   51   64    77    1.234   0.456   0.012

手动同步时间：

ntpdate 192.168.0.2         #192.168.0.2 为时间服务器

上述结果表示本地时间比标准服务器慢 0.456 毫秒。

2.2.3 clockdiff 方式

clockdiff
 用于测量本地主机与远程主机之间的时间差异，其不属于 NTP（Network Time Protocol，网络时间协议）核心命令集，也与 chronyc
 无关联。

执行命令检查时间是否同步：

[root@localhost ~]# clockdiff 10.186.56.44
.
host=10.186.56.44 rtt=750(187)ms/0ms delta=-29ms/-29ms Tue Aug 22 13:15:16 2023
//delta 的值小于 100ms，说明时间同步情况良好

2.3 检查网络延迟

执行命令：

[root@10-186-56-26 ~]# ping -c 5 194.58.202.20
PING 194.58.202.20 (194.58.202.20) 56(84) bytes of data.
64 bytes from 194.58.202.20: icmp_seq=1 ttl=44 time=284 ms
64 bytes from 194.58.202.20: icmp_seq=2 ttl=44 time=285 ms
64 bytes from 194.58.202.20: icmp_seq=3 ttl=44 time=282 ms
64 bytes from 194.58.202.20: icmp_seq=4 ttl=44 time=282 ms
64 bytes from 194.58.202.20: icmp_seq=5 ttl=44 time=282 ms
--- 194.58.202.20 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 282.491/283.667/285.652/1.467 ms

关键参数说明：

• -c 5
  ：指定发送数据包的数量（可根据需求调整）。

结果判断： 若输出结果中大部分 time
 值大于 100ms，或平均值（avg）大于 100ms，则说明网络延迟较高。

2.4 检查集群节点上 OBSERVER 相关目录结构及权限

检查以下三个目录是否拥有 admin 权限，以及是否存在多余文件：

/home/admin/oceanbase
/data/1
/data/log1

2.5 检查 OBServer 的 clog 目录是否有足够的可用空间

OBServer 默认会在 clog 所在目录已用空间达到 95% 时（受参数 log_disk_usage_limit_percentage 控制）日志停写。 如果 OBServer 的 clog 目录占用（不论是 OBServer clog 或者其他文件）已经超过了 95%，就会引起 OBServer BOOTSTRAP 失败。

2.6 检查集群进行 BOOTSTRAP 操作时系统资源是否不足

OB 集群在进行 BOOTSTRAP 操作时系统资源不足，例如 CPU、内存等资源不足。系统资源不足时，可能报 OB_INVALID_RESOURCE_UNIT 相关错误信息 ；但是如果资源足够，但是仍然报错，需要进行进一步诊断确认 BOOTSTRAP 超时的原因。

2.7 检查每个 OBServer 是否使用相同的 cluster_id 启动

在启动 OBServer 的时候，需要指定合法的 cluster_id，cluster_id 的合法取值范围是 [1,4294901759]。

3. 总结

针对 Bootstrap ob 报错问题，原因复杂多样。通用的排查手段，笔者认为目前从两方面排查。

1. 检查 OBServer.log 日志：OBServer.log
    日志往往会提供相应的排查方向，方便快读定位问题原因。

2. 按照上述其他常见原因逐一排查。