--- title: RS 启动失败在 ObTTLScheduler::start-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于RS 启动失败在 ObTTLScheduler::start相关的常见问题和使用技巧，帮助您快速解决RS 启动失败在 ObTTLScheduler::start的难题。 --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 划线反馈 # RS 启动失败在 ObTTLScheduler::start 更新时间：2026-06-12 07:31 适用版本： V3.2.x、V3.1.x 内容类型：Troubleshoot ## 问题现象 大流量的压测，同时中途出现 RS 切主，切主后新的 RS Leader 启动一直失败，失败在 ObTTLScheduler::start，日志中有如下信息。 ```shell rootservice.log:[2023-07-05 12:56:45.590205] WDIAG [RS] ob_ttl_scheduler.cpp:1451 [18877][0][Y3B9764586C0E-0005FF9F791AB593-0-0] [lt=9] [dc=0][errcode=-4016] init ttl scheduler fail(ret=-4016) rootservice.log:[2023-07-05 12:56:45.590221] WDIAG [RS] ob_root_service.cpp:7072 [18877][0][Y3B9764586C0E-0005FF9F791AB593-0-0] [lt=11] [dc=0][errcode=-4016] fail to start ttl scheduler(ret=-4016) rootservice.log:[2023-07-05 12:56:45.590246] EDIAG [RS] ob_root_service.cpp:16949 [18877][0][Y3B9764586C0E-0005FF9F791AB593-0-0] [lt=10] [dc=0][errcode=-4016] rs_monitor_check : fail to start root service(ret=-4016, ret="OB_ERR_UNEXPECTED", count=1550) BACKTRACE:0x1df2bc80 0x1def83d9 0x6f5ddde 0x6f5d928 0x6f5d555 0x744e0e5 0xed24572 0xeb57824 0xeb758bb 0xeb73e31 0xebf74bd 0x1e264528 0x1e26ea94 0x1e26dec3 0x74435ab 0x1d36ade6 0x1d36a9d9 0x1ef260af ``` ## 问题原因 - RS 异步任务依赖流程重试机制需要可重入的支持。然而，`ttl_scheduler_.start` 函数内部开启了一个定时器，而定时器的打开是不可重入的。因此，如果在 `ttl_scheduler_` 函数后面的操作执行失败,重试 `ttl_scheduler_.start` 会一直报错 `-4016（OB_ERR_UNEXPECTED）`。 - 目前压测场景中发现 `ttl_scheduler_` 启动后有一条访问 `__all_core_table` 的 SQL 执行返回 `-6004（OB_ERR_SHARED_LOCK_CONFLICT）`，从而导致了整个流程重试。原因主要是因为当前系统负载过高（系统 CPU 利用率过高），导致当前处于 prepare 阶段的 `__all_core_table` 写事务一直没有完成 `commit`，`commit` 阶段主要是写日志时间比较长。 ## 问题的风险及影响 在系统高负载并进行 RS 切主操作时，该问题会导致 RS 一直启动失败，无法提供完整服务。 ## 影响版本 - OceanBase 数据库企业版 V3.2.4 BP4（oceanbase-3.2.4.4-104000052023062021）、V3.2.4 BP4 Hotfix1（oceanbase-3.2.4.4-104010012023062711）、V3.2.4 BP4 Hotfix2（oceanbase-3.2.4.4-104020012023070316）版本。 - OceanBase 数据库社区版 V3.1.4（oceanbase-ce-3.1.4-10000092022071511）、V3.1.5（oceanbase-ce-3.1.5-100000252023041721） 版本。 ## 解决方法及规避方式 ### 解决方法 当问题出现后，当前 RS Leader 会一直处于 `IN_SERVICE` 状态，无法切换到 `FULL_SERVICE` 状态，不能提供完整服务，需要触发 RS 重新启动，可以采用尝试下面两种方法。 - 强制宕机 RS Leader 所在的 OBServer，触发 RS Leader 切换到其他机器。 - 如果不能直接宕机，可以通过 `ob_admin batch_switch_rs_leader` 命令手动切换 RS leader 到其他机器上，示例如下。 ```sql ob_admin batch_switch_rs_leader [options] ... ``` 其中：table_id1、 partition_id1、 replica_id1、 ... 指的是要切换 Leader 的副本服务器的信息，可以是一个或多个副本服务器的组合。每个副本服务器信息包括表 ID（table_id）、分区 ID（partition_id）和副本 ID（replica_id）。 可用的选项（options）包括： - -f ：强制执行 Leader 切换，即使存在正在进行的任务。默认为 false。 - -c ：指定集群 ID，用于在多集群环境下指定要切换的集群。默认为当前集群 ID。 ### 规避方式 该问题是 RS 启动的时候可能偶现的问题，目前看触发该问题的环境比较恶劣，都是 CPU 负载高同时出现 RS 切主的情况，可以考虑尽量减少 RS 切主频率，尤其是在整个系统压力比较大的时候，进而减少问题发生的概率。建议最好还是升级到最新已修复版本。 目前已修复的版本包括 OceanBase 数据库企业版 V3.2.4 BP4 Hotfix3（oceanbase-3.2.4.4-104030012023070623）版本。 上一篇 [RS 自检线程报错 thread hang](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000225634) 下一篇 [如何确认每个租户的 GTS 的 Leader 位置](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000366657) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线