oceanbase 1-1-1 集群手动重启sys租户登录一直处于Server is initializing状态

【 使用环境 】生产环境
【 OB or 其他组件 】 oceanbase
【 使用版本 】
【问题描述】
ocp部署的,通过杀进程,在安装目录上手动启动observer进程,登录sys租户登录一直处于Server is initializing状态,启动顺序是3个节点逐一杀进程后,逐一启动。

ob日志一直相似的滚动。详细见附件

observer.log.zip (17.5 MB)

[2025-09-23 16:29:16.418625] WDIAG [COORDINATOR] refresh (election_priority_impl.cpp:268) [33731][T1001_L0_G2][T1001][YF5A2C0A80AA3-00063F72CBE4B780-0-0] [lt=10][errcode=-4018] refresh priority failed(ret=-4018, ret=“OB_ENTRY_NOT_EXIST”, MTL_ID()=1001, ls_id={id:1}, *this={priority:{is_valid:false, is_observer_stopped:false, is_server_stopped:false, is_zone_stopped:false, fatal_failures:[], is_primary_region:false, serious_failures:[{type:SCHEMA NOT REFRESHED, module:SCHEMA, info:schema not refreshed, level:SERIOUS}], is_in_blacklist:false, in_blacklist_reason:, scn:{val:0, v:0}, is_manual_leader:false, zone_priority:9223372036854775807}})
[2025-09-23 16:29:16.418729] WDIAG [COORDINATOR] compare_with (election_priority_impl.cpp:212) [33731][T1001_L0_G2][T1001][YF5A2C0A80AA3-00063F72CBE4B780-0-0] [lt=52][errcode=0] compare between invalid priority
[2025-09-23 16:29:16.423827] WDIAG [SQL] do_close_plan (ob_result_set.cpp:850) [33372][T1_FreInfoReloa][T1][YF5A2C0A80AA3-00063F72CEB45B11-0-0] [lt=0][errcode=-4006] exec result is null(ret=-4006)
[2025-09-23 16:29:16.423836] WDIAG [SQL] do_close (ob_result_set.cpp:947) [33372][T1_FreInfoReloa][T1][YF5A2C0A80AA3-00063F72CEB45B11-0-0] [lt=6][errcode=0] fail close main query(ret=0, do_close_plan_ret=-4006)
[2025-09-23 16:29:16.423870] WDIAG [SQL.PC] common_free (ob_lib_cache_object_manager.cpp:141) [33372][T1_FreInfoReloa][T1][YF5A2C0A80AA3-00063F72CEB45B11-0-0] [lt=0][errcode=0] set logical del time(cache_obj->get_logical_del_time()=4945347077236, cache_obj->added_lc()=false, cache_obj->get_object_id()=42004, cache_obj->get_tenant_id()=1, lbt()=“0x7bb5945 0xfb02508 0x74dc8b4 0x78d9087 0x77e5bc9 0xef4b6f7 0x77ded10 0x77d1d9a 0x77d1caf 0x77c2426 0x7d9b153 0x188a9349 0x7841d7a 0x783b973 0x1f5af0a8 0x1f5ad20e 0x7f55fa64bea5 0x7f55fa374b0d”)
[2025-09-23 16:29:16.428216] WDIAG [SHARE.SCHEMA] get_tenant_schema_guard (ob_multi_version_schema_service.cpp:1176) [33675][T1001_ReqMemEvi][T1001][Y0-0000000000000000-0-0] [lt=6][errcode=-5627] get tenant schema store fail, maybe local schema is old(ret=-5627, tenant_id=1001)
[2025-09-23 16:29:16.428232] WDIAG get_global_sys_variable (ob_basic_session_info.cpp:1057) [33675][T1001_ReqMemEvi][T1001][Y0-0000000000000000-0-0] [lt=12][errcode=-4029] fail get schema guard(ret=-4029)

日志没有相关信息,麻烦提供一份覆盖重启期间日志

重启日志已经被覆盖了,后来我们发现3节点中2个节点clog快满了出现报错,用命令行重启,等待了一晚上恢复成功
./bin/observer -o “log_disk_size=80G,log_disk_utilization_threshold=95,log_disk_utilization_limit_threshold=98”
后来确实发现业务租户元数据租户META$1002(1001)被分配的磁盘不足,因为1002租户logdisk只给了30G,后扩大到了40G,再重启又起不来了,12小时都没起来。业务租户35g,logdisk应该给100g,当时资源比较少,就只扩展了一点,似乎还是不够。
新的启动命令是
./bin/observer -o “log_disk_size=200G,log_disk_utilization_threshold=99,log_disk_utilization_limit_threshold=99”
日志如下:
节点1:


节点2:

目前我们要继续等待么,有什么方法可以看恢复进度,又或者参数怎么调整

你的1002租户规格多大?
这种风险有点大了,log_disk_utilization_limit_threshold改为100后需要扩容租户的log盘参数,如果没成功扩容,就没办法处理了

1002租户35g内存,给了40g磁盘,我们启动后计划扩容,目前有什么办法看看进度,谢谢您了

log_disk_utilization_limit_threshold 修改100是不是风险有点大,目前这种状态是否可以通过等待他自己恢复,我们如何确认只是在不断重复尝试,还是有所进度。

恢复的几率不大,log大小设置建议为内存的3-4倍 40G太小了。修改100后直接alter给150G就可以了

log_disk_utilization_limit_threshold 修改100 会不会摧毁数据呀,谢谢了,目前数据库是在尝试回收clog空间么

不会摧毁数据。你的租户log盘太小了,目前应该不会自动尝试回收

这个文档里面说log_disk_utilization_limit_threshold是停写阀值,但是调整这个参数后,在报错日志里limit_percent 仍然是95%,是不是这个参数修改其实没有生效?

https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001092703?back=kb

image
这里报错的是1002租户的meta租户。所以可能总统计并为达到99%。meta租户会占用10%的资源