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

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

划线反馈

# 主备库排查手册

更新时间：2025-06-23 06:56

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

本文介绍主备库相关问题的排查方法。

## 适用版本

OceanBase 数据库 V4.x 版本。

## 查询租户操作历史

### 查看 Switchover 操作历史

在系统租户下执行如下 SQL 查询。

```shell
obclient> SELECT * FROM DBA_OB_ROOTSERVICE_EVENT_HISTORY
WHERE EVENT LIKE "%switchover to%" ORDER BY TIMESTAMP;

```

### 查看 Switchover 同步完成后的准备切换位点

在系统租户下执行如下 SQL 查询。

```shell
obclient> SELECT * FROM DBA_OB_ROOTSERVICE_EVENT_HISTORY
WHERE EVENT = "wait sync to latest end" and extra_info like "%tenant id:100X%" ORDER BY TIMESTAMP;

```

通过查看结果中的 `finished` 字段，检查备租户是否已经同步完恢复源的日志。 当 `finished` 为 `yes` 时，表示已经同步完成，接下来继续执行如下 SQL，查看日志流具体切换位点。

```shell
obclient> SELECT * FROM DBA_OB_ROOTSERVICE_EVENT_HISTORY
WHERE EVENT = "wait tenant sync from latest" and extra_info like "%tenant id:100X%" ORDER BY TIMESTAMP;

```

由于这个 event 会在 Switchover 等待日志流同步过程中持续打印，需要观察最新的一行结果。

### 查看 Failover 操作历史

在系统租户下执行如下 SQL 查询。

```shell
obclient> SELECT * FROM DBA_OB_ROOTSERVICE_EVENT_HISTORY
WHERE EVENT LIKE "%failover to primary%" ORDER BY TIMESTAMP;

```

### 查看为租户设置恢复源操作历史

在系统租户下执行如下 SQL 查询。

```shell
obclient> SELECT * FROM DBA_OB_ROOTSERVICE_EVENT_HISTORY
WHERE event = "%admin_set_config%" and value2 like "log_restore_source" ORDER BY TIMESTAMP;

```

### 查看为租户设置归档目的端操作历史

在系统租户下执行如下 SQL 查询。

```shell
obclient> SELECT * FROM DBA_OB_ROOTSERVICE_EVENT_HISTORY
WHERE event = "%admin_set_config%" and value2 like "log_archive_dest" ORDER BY TIMESTAMP;

```

### 查看为租户日志流 leader 切换历史

在系统租户下执行如下 SQL 查询。

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

```

### 查看 recover 命令操作历史

在系统租户下执行如下 SQL 查询。

```shell
obclient> SELECT * FROM DBA_OB_ROOTSERVICE_EVENT_HISTORY
WHERE EVENT LIKE "%recover_tenant%" ORDER BY TIMESTAMP;

```

## 主备库同步问题

要排查主备库同步问题，首先需要明确主备库日志同步的数据流。具体主备库同步 clog 和统计同步进度方法如下：

主租户产生 clog->归档目的端->备租户拉取日志->备租户统计日志流同步进度->备租户统计租户同步进度。

在主备库日志同步的数据流的每一步都有可能导致主备库同步出现问题。因此排查问题的方式就是沿着以上路径进行排查。

### 主备库同步延迟

排查主备库延迟有 2 种场景，一种是持续有延迟，另一种为过去某段时间有延迟。 对于这两种延迟，区别是是否有现场，排查方法也有一些区别。为此，分别说明这两种延迟的排查方法。

#### 过去某段时间有延迟

1. 明确备库同步延迟较大的 LS，并确定开始出现延迟的时间。

      1. 在有延迟的时间点附近，在备库 OBServer 上查找 LS leader 汇报同步位点的日志

        ```shell
        obclient> select * from GV$OB_LOG_STAT where TENANT_ID = 10XX and role='LEADER';

        ```

        ```sql
        grep "tenant update ls recovery stat" rootservice.log|grep T100X

        ```
      2. 根据结果中的 `sync_scn:{val:xxxx}`, 查看 LS 汇报的 `sync scn` 和日志的时间比较是否有延迟。从而确定开始出现延迟的时间和出现延迟的 LS。
 2. 检查到归档目的端是否有延迟。

      1. 在主租户有延迟的 LS leader 所在的 OBServer 上，执行如下命令。

        ```sql
        grep "ARCHIVE\] update_archive_progress" observer.log｜grep T10XX_ArcSender

        ```
      2. 根据结果中的 `scn:{val:xxxx}`, 查看当前归档是否有延迟。
 3. 在备库租户上查看备库拉取主库 log 是否有延迟。

   ```sql
   grep "T10XX_RFLWorker" observer.log

   ```

   查看日志中是否有 `get piece cost too much time` 信息，如果有则说明拉取主库 log 有延迟。

#### 持续有延迟

1. 查看备租户是否有同步延迟。

      1. 在备租户的 SQL 客户端上执行如下 SQL 查询。

        ```sql
        obclient> select SCN_TO_TIMESTAMP(SYNC_SCN),current_timestamp(6)
        from DBA_OB_TENANTS
        where TENANT_TYPE='USER' and TENANT_ID=100X;

        ```
 2. 明确备租户同步延迟较大的 LS。

      1. 在备租户的 SQL 客户端上执行如下查询，找到延迟最大的 LS，并查看 SCN 是否在持续推进。

        ```shell
        obclient> select SCN_TO_TIMESTAMP(min(end_scn)),current_timestamp(6), ls_id, svr_ip,svr_port
        from GV$OB_LOG_STAT
        where TENANT_ID=100X and role='LEADER';

        obclient> SELECT MIN(SYNC_SCN) FROM CDB_OB_LS WHERE TENANT_ID=10XX;

        ```
 3. 在主租户查看对应日志流的归档状态。

      1. 在主租户的 SQL 客户端上执行如下查询，查看租户归档是否正常。

        ```shell
        obclient> SELECT * FROM V$OB_ARCHIVE_DEST_STATUS WHERE TENANT_ID = 10XX;

        ```
      2. 在主租户的 SQL 客户端上执行如下查询，查看租户日志流归档是否正常。

        ```shell
        obclient> select tenant_id,CHECKPOINT_SCN,SCN_TO_TIMESTAMP(CHECKPOINT_SCN), current_timestamp(6),STATUS
        from CDB_OB_LS_LOG_ARCHIVE_PROGRESS
        where LS_ID=10XX and TENANT_ID = 10XX;

        ```
 4. 是否主备租户规格不同导致恢复日志慢，在步骤 2 中找到最落后日志所在的 OBServer，查看恢复日志的线程日志。

   ```sql
   grep T100X_RFL observer.log

   ```

   有如下日志打印 `clog disk is not enough, just wait` 表明 clog 盘满无法提交日志。

### 主备库同步卡住

1. 首先确认备库日志是否恢复源设置错误。
 2. 确认备租户同步是否卡住。

      1. 在备租户的 SQL 客户端上执行如下查询，查看 `SYNC_SCN` 是否在持续推进，如果 `SYNC_SCN` 不动，则表示同步卡住。

        ```shell
        obclient> SELECT * FROM DBA_OB_TENANTS WHERE TENANT_NAME='XXX'\G

        ```
 3. 查看备租户同步卡住的 LS。

      1. 在备租户的 SQL 客户端上执行如下查询，查看租户日志流统计是否卡住。如果 `SYNC_SCN` 不动，则表示同步卡住。

        ```shell
        obclient> SELECT MIN(SYNC_SCN) FROM CDB_OB_LS WHERE TENANT_ID=10XX;

        ```
      2. 根据 `MIN(SYNC_SCN)` 的数值，在备租户的 SQL 客户端上执行如下查询，查看租户日志流信息。

        ```shell
        obclient> SELECT TENANT_ID, LS_ID, CREATE_SCN, READABLE_SCN, SYNC_SCN, DROP_SCN FROM CDB_OB_LS WHERE SYNC_SCN = xxxx;

        ```
      3. 根据获得的 LS 信息，在备租户的 SQL 客户端上执行如下查询，查看租户日志流同步是否正常。

        ```shell
        obclient> SELECT TENANT_ID, LS_ID, SVR_IP, SVR_PORT, ROLE, IN_SYNC, END_SCN
        FROM GV$OB_LOG_STAT
        WHERE TENANT_ID=100X AND LS_ID = 100X AND ROLE = 'LEADER';

        ```
 4. 在主租户查看对应日志流的归档状态。

        ```
 5. 如果发现主租户的归档正常，则检查备租户的拉取归档日志线程是否有报错。

      1. 在备租户对应日志流的 leader 所在 OBServer上，查询 `remote fetch log` 模块是否工作正常。

        ```

### 常见的同步问题原因

#### 云上 OSS 环境，日志流切主导致一段时间（10s～3min）内有延迟

日志流切主之后需要读取整个归档文件来构建日志流上下文，单个文件可能需要 10～15 秒来完成构建，构建完成后，才可以开始从恢复源拉取日志，此时会造成主备库同步延迟。

延迟叠加效应： 由于一个租户的多个日志流是串行构建的，当多个日志流同时切主后，会造成后处理的日志流有更长的延迟时间，由于租户的同步进度统计的是所有日志流的同步进度，会导致租户整体同步进度延迟更多。

#### Switchover 报错

Switchover 备切主命令可能出错，下面列举了场景的错误信息、原因以及处理方法。

#### 场景一: 报错 `not sync to latest, switch to primary`

问题原因:备租户切换成主租户时，没有同步到归档所有的日志。

处理方法:检查备租户的同步进度，并与主租户的归档进度进行比较。

#### 场景二: 报错 `Timeout`

问题原因: timeout 的原因较多，需要根据日志进行排查。

处理方法:

1. 在备租户的 SQL 客户端上执行如下查询，查看 switchover 的执行 trace。

   ```shell
   obclient> SELECT * FROM DBA_OB_ROOTSERVICE_EVENT_HISTORY
   WHERE EVENT LIKE "%switchover to%";

   ```

   查询结果的示例如下：

   ```sql
   +----------------------------+---------------+--------------------------------+------------+---------+-------+--------+-------+--------+-------+--------+-------+--------+---------+--------+-----------------------------------------------------------------------------------------------------------------------------------------------------+--------------+-------------+
   | TIMESTAMP                  | MODULE        | EVENT                          | NAME1      | VALUE1  | NAME2 | VALUE2 | NAME3 | VALUE3 | NAME4 | VALUE4 | NAME5 | VALUE5 | NAME6   | VALUE6 | EXTRA_INFO                                                                                                                                          | RS_SVR_IP    | RS_SVR_PORT |
   +----------------------------+---------------+--------------------------------+------------+---------+-------+--------+-------+--------+-------+--------+-------+--------+---------+--------+-----------------------------------------------------------------------------------------------------------------------------------------------------+--------------+-------------+
   | 2023-02-27 17:45:58.900263 | cluster_event | switchover to physical standby | event_type | CONTROL | ret   | 0      |       |        |       |        |       |        | message |        | flag:"start", stmt_str:"alter system switchover to standby tenant mysql_tenant", trace_id:Y4F06C0A80030-0005F5AA7B8584D5-0-0                        | 192.168.x.xx |       20230 |
   | 2023-02-27 17:45:59.219667 | cluster_event | switchover to physical standby | event_type | CONTROL | ret   | 0      |       |        |       |        |       |        | message |        | flag:"finish", cost:319405, stmt_str:"alter system switchover to standby tenant mysql_tenant", trace_id:Y4F06C0A80030-0005F5AA7B8584D5-0-0          | 192.168.x.xx |       20230 |
   +----------------------------+---------------+--------------------------------+------------+---------+-------+--------+-------+--------+-------+--------+-------+--------+---------+--------+-----------------------------------------------------------------------------------------------------------------------------------------------------+--------------+-------------+

   ```

   `RS_SVR_IP` 和 `RS_SVR_PORT` 表示了 switchover 命令执行的 OBServer。
 2. 登陆到目标 OBServer，根据 `trace_id` 查看 switchover 的执行日志。

   ```sql
   grep Y4F06C0A80030-0005F5AA7B8584D5-0-0 rootservice.log
   grep Y4F06C0A80030-0005F5AA7B8584D5-0-0 observer.log

   ```

   执行过程中可能会发送 RPC，需要根据 RPC 的目标端 IP，查看对端的执行日志。

### Failover 报错

1. 在备租户的 SQL 客户端上执行如下查询，查看 failover 的执行 trace。

   ```sql
   SELECT * FROM DBA_OB_ROOTSERVICE_EVENT_HISTORY
   WHERE EVENT LIKE "%failover to primary%";

   ```

   查询结果的示例如下:

   ```shell
   +----------------------------+---------------+---------------------+------------+---------+-------+--------+-------+--------+-------+--------+-------+--------+---------+--------+----------------------------------------------------------------------------------------------------------------------------+--------------+-------------+
   | TIMESTAMP                  | MODULE        | EVENT               | NAME1      | VALUE1  | NAME2 | VALUE2 | NAME3 | VALUE3 | NAME4 | VALUE4 | NAME5 | VALUE5 | NAME6   | VALUE6 | EXTRA_INFO                                                                                                                 | RS_SVR_IP    | RS_SVR_PORT |
   +----------------------------+---------------+---------------------+------------+---------+-------+--------+-------+--------+-------+--------+-------+--------+---------+--------+----------------------------------------------------------------------------------------------------------------------------+--------------+-------------+
   | 2023-02-27 17:45:58.900263 | cluster_event | failover to primary | event_type | CONTROL | ret   | 0      |       |        |       |        |       |        | message |        | flag:"start", stmt_str:"ALTER SYSTEM ACTIVATE STANDBY", trace_id:Y4F06C0A80030-0005F5AA7B8584D5-0-0                        | 192.168.x.xx |       20230 |
   | 2023-02-27 17:45:59.219667 | cluster_event | failover to primary | event_type | CONTROL | ret   | 0      |       |        |       |        |       |        | message |        | flag:"finish", cost:319405, stmt_str:"ALTER SYSTEM ACTIVATE STANDBY", trace_id:Y4F06C0A80030-0005F5AA7B8584D5-0-0          | 192.168.x.xx |       20230 |
   +----------------------------+---------------+---------------------+------------+---------+-------+--------+-------+--------+-------+--------+-------+--------+---------+--------+----------------------------------------------------------------------------------------------------------------------------+--------------+-------------+

   ```

   `RS_SVR_IP` 和 `RS_SVR_PORT` 表示了 failover 命令执行的 OBServer。
 2. 登陆到目标 OBServer，根据 `trace_id` 查看 failover 的执行日志。

   ```
 3. 执行过程中可能会发送 RPC，需要根据 RPC 的目标端 IP，查看对端的执行日志。

上一篇

[OceanBase 数据库 V3.x 版本中查看 v$ob_cluster 发现 switchover_status 为 not_allow](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000005462601)

下一篇

[OceanBase 数据库仲裁服务](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000261688) ![有帮助](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) 咨询热线