---
title: RTO 耗时长排查文档-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于 RTO 耗时长排查文档相关的常见问题和使用技巧，帮助您快速解决 RTO 耗时长排查文档的难题。
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

# RTO 耗时长排查文档

更新时间：2024-05-24 02:16

适用版本： V4.1.x、V4.2.x 内容类型：Troubleshoot  

在正常情况下，多个异常故障场景，如 `kill -9`, 断网，磁盘故障等场景的故障恢复时间在 8 秒以内（RTO < 8s）。

本文档将介绍当 RTO 未达到预期水平时，如何快速定位故障原因。

按照故障切换的流程逐步进行分析。需要注意的是，以下排查日志不可以指定单一 `ls id`，需要租户下的所有日志流都正常走完流程才能认为此租户正常切换成功。

## 选举层切主

旧 Leader 的故障被感知到后，根据不同场景的故障采取不同的切主方式。无主选举耗费时间为 4s，有主改选耗费时间为 1ms，故障检测到选举切主的最长 GAP 为两次续约间隔为 500ms。

- 如果环境可以直连，通过 SQL 可以快速查找 RTO 切换附近选举层切主的事件。

  ```shell
  obclient> SELECT gmt_create,svr_ip,svr_port,event,name3,value2,value3 FROM __all_server_event_history WHERE module="ELECTION" AND value1=$tenant_id AND gmt_create like '$rto_time' ORDER BY gmt_create;

  ```

  ![1](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/synchronization-and-election/leader/rto-takes-a-long-time-to-troubleshoot-documents/1.png)
 - 通过日志判断。

  ```shell
  grep 'T$tenant_id.*role change' election.log

  ```

  ![2](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/synchronization-and-election/leader/rto-takes-a-long-time-to-troubleshoot-documents/2.png)

  可以搜到对应日志流上任的日志。

  如果搜到的选举切主时间大幅落后于预期时间，需要进一步排查选举切主的问题，分析思路类似于无主问题。

## Palf 层 reconfirm

选举层正常切主后，新主需要按流程上任工作，下一步为 palf 层的上任，搜索日志。

```bash
grep 'to_leader_reconfirm.*T$tenant_id' observer.log

```

![3](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/synchronization-and-election/leader/rto-takes-a-long-time-to-troubleshoot-documents/3.png)

此日志代表 palf 层 reconfirm 开始时间，一般和选举层切主时间无延迟。

继续搜索日志

```bash
grep 'T$tenant_id.*to_leader_active_ finished' observer.log

```

![4](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/synchronization-and-election/leader/rto-takes-a-long-time-to-troubleshoot-documents/4.png)

此日志代表 palf 层 reconfirm 完成时间，考虑到拉日志及写特殊上任日志所需要的交互时间，认为 reconfirm 的花费时间最多不超过 1s，否则可以搜索耗时过久的日志流对应的 reconfirm 全体日志，查看重复打印的日志可基本定位耗时长的部分。

## RoleChange Service takeover

election，palf 上任后，最后一步需要上任的模块为 log handler。目前 rolechancge service 在租户内为单线程，所以不同日志流只能串行上任，首先先搜索所有日志流的 rolechange event 被 handle 的起始时间

```bash
grep 'T$tenant_id_RCS.*begin handle_role_change_event_' observer.log

```

![5](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/synchronization-and-election/leader/rto-takes-a-long-time-to-troubleshoot-documents/5.png)

再次找到对应的事件结束的时间，可以对应查看是否某个日志流的上任过程耗时较长影响了其他的日志流。如果有此类情况，则 grep 当时的 RCS 线程确定具体耗时长的模块即可。

```bash
grep 'T$tenant_id_RCS.*switch_follower_to_leader_ success' observer.log

```

![6](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/synchronization-and-election/leader/rto-takes-a-long-time-to-troubleshoot-documents/6.png)

## Location Cache 刷新

截止到此，RTO 在日志部分的工作已经完成，新 leader 已经正常上任并可以工作了。但新 leader 还并未刷新到 Location Cache，上层还不能识别到新 leader。刷新 Location Cache 是有后台线程定期触发的，并且 log handler 上任成功时也会主动汇报一次，关键日志如下：

```bash
grep 'T$tenant_id_RCS.*async_update' observer.log

```

![7](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/synchronization-and-election/leader/rto-takes-a-long-time-to-troubleshoot-documents/7.png)

但汇报本身是一个异步 SQL，可能因为 SQL 队列满，慢 SQL 等各种可能的原因导致汇报耗时很长。需要找到 Location 刷新完成的日志：

```bash
grep 'ls location cache has changed.*tenant_id:$tenant_id' observer.log

```

![8](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/synchronization-and-election/leader/rto-takes-a-long-time-to-troubleshoot-documents/8.png)

如果发现 Location 刷新成功和 log handler 上任之间的 GAP 很大，需要进一步递归的搜索 meta 租户和 sys 租户的 Location 刷新时间，具体如下：

![9](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/synchronization-and-election/leader/rto-takes-a-long-time-to-troubleshoot-documents/9.png)

Server 故障时，可能因为队列积压导致汇报 Location 卡住。在 OceanBase 数据库 V4.1 版本，RS 额外提供了一套通过 RPC 刷新 Location 的逻辑，此 RPC 使用高优先级队列，预期不会因为积压导致卡住。具体线程如下：

```bash
grep 'AutoLSLocRpc' observer.log

```

此线程在没有 Location 变更时预期 10s 打印一条日志。

![10](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/synchronization-and-election/leader/rto-takes-a-long-time-to-troubleshoot-documents/10.png)

当探测到 Location 变更时，会打印 leader 变更的日志。

![11](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/synchronization-and-election/leader/rto-takes-a-long-time-to-troubleshoot-documents/11.png)

如果在 TPS 跌 0 时间段没有发现此线程的打印日志，则需要继续分析是否有死锁或其他问题。

## 适用版本

OceanBase 数据库 V4.1.x、V4.2.x 版本。

上一篇

[OBServer 切主后回放日志报错 ERROR 6205(OB_TRANS_INVALID_STATE)](https://www.oceanbase.com/knowledge-base/oceanbase-database-20000045536)

下一篇

[RS 自检手段](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001267148) ![有帮助](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) 咨询热线