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

- 简体中文
- English

划线反馈

# OceanBase 数据库 V4.x 版本中 Location Service 问题排查

更新时间：2025-07-28 09:16

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

## 基础知识

OceanBase 数据库 V4.x 版本由于单机日志流改造，原先的分区副本位置信息被拆分成两部分：1.tablet->LS 映射关系；2. LS 副本位置。

![image001](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/2020406214xlocationservice001.png)

为了提高访问性能，OceanBase 数据库对两层信息均进行了缓存，分别是 `ObTabletLSCache` 和 `ObLSLocation`，由 `ObLocationService` 模块统一管理。

### LS Location

`LS Location` 缓存的是 `PALF` 层 `LS leader` 。（leader上任包含 `election`、`PALF`、`RoleChangeService` 三层）。若底层发生切主，`LS Location` 最长延迟 1s（1s 内缓存旧都符合预期） 即可感知到正确 `LS leader` 。

在 OceanBase 数据库 V4.2.1 及之后版本，`LS location` 拥有 `RPC` 主动刷新和 SQL 主动刷新两种主动刷新能力，`RPC` 主动刷新间隔 1s 专门感知 `LS leader`，SQL 主动刷新依赖 meta 表，间隔 10s 感知所有副本。可以认为 `LS Location` 99.9% 都是正确的。

### Tablet Location

`Tablet Location`（`ObTabletLSCache`，tablet->LS 映射关系缓存）主要依赖调用方根据错误码重试时触发 Location 刷新。

映射关系的变化主要发生在建表、删表、分区修改等 DDL 场景以及 `transfer` 场景。对于 DDL 场景导致的 `TabletLSCache` 变化，不具备主动刷新能力，需要使用者根据错误码被动触发 Location 刷新并进行重试。 针对 `transfer` 场景，在 OceanBase 数据库 V4.2.1 BP2、V4.2.2、V4.3.0 版本中引入了基于 transfer 的主动刷新能力，极大程度缓解了 `transfer` 后 tablet->LS 映射不准导致的各类问题。

## LS Location 问题排查

关联错误码：

- -4038 OB_NOT_MASTER
 - -4721 OB_LS_LOCATION_NOT_EXIST
 - -4722 OB_LS_LOCATION_LEADER_NOT_EXIST

1. 排查切主或无主。

   认为 `LS Location` 存在问题时，99.9% 都是底层发生切主或者无主，`LS Location` 是符合预期的（1s 以内感知正确 leader 均符合预期）。

      1. 查看当前 leader 。

        ```shell
        select * from oceanbase.__all_virtual_ha_diagnose where tenant_id=xxxx and ls_id=xxxx;

        ```
      2. 查看历史 leader 。

        无主排查详见：[V4.0 无主问题排查手册](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001230454?back=kb)

        ```shell
        ## 1. 选举层 leader 。
        SELECT * FROM oceanbase.__all_server_event_history WHERE module="election" AND value1=$tenant_id AND value2=$ls_id ORDER BY gmt_create desc limit 20;

        ```

        ```shell
        ## 2. PALF 层 leader 。
        SELECT * FROM __all_server_event_history WHERE module="log" AND value1=$tenant_id AND value2=$ls_id AND event like "%ROLE TRANSITION%" ORDER BY gmt_create desc limit 20;

        ```

        或查看日志：

        ```shell
        grep 'Txxxx_.*PALF_DUMP.*palf_id=xxxx,' observer.log.* | less

        ```

        ```shell
        ## 3. RCS 层 leader 。
        grep 'Txxxx_RCS' observer.log.xxxx rootservice.log.xxxx -h | sort | less

        ```
 2. 确认 LS location 缓存

   日志关键字： **[LS_LOCATION]** 。

   具体查询方法，如下。

      1. 明确 location 异常的机器 server_addr，确认异常的时间、tenant_id、ls_id 。
      2. `fgrep "[LS_LOCATION]" observer.log.xxxxx` 即可查看对应时间点 `location cache` 变化。在 `ls location` 发生变化时会打印对应变化日志。每 30s 也会 dump 一次 cache 所有内容。均可用来证明 `ls location` 的正确性。

        ![image02](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/202406214xlocationservice002.png)

## Tablet location 问题排查

- 关联错误码：

     - -4723 OB_MAPPING_BETWEEN_TABLET_AND_LS_NOT_EXIST
     - -4725 OB_TABLET_NOT_EXIST
 - 符合预期的场景：

     - 当从未访问过对应 tablet 时，没有缓存，报错 -4723 符合预期。对应路径需要刷新 location 后重试。
     - transfer 过程中 tablet 会临时无法访问，可能报错 -4725（预估持续毫秒级时间）符合预期。对应路径应该刷新 location 后重试。
     - tablet 被删除后，获取 tablet location 报错-4723，访问 tablet 报错 -4725 均符合预期。
     - 弱读场景，SQL 持续打到非 leader 机器符合预期。

1. 明确报错路径。

      - 弱读场景持续不可读，累计多个 BUG，SQL 层路由时会自己选择非 leader 副本读取，同时会通过黑名单过滤掉异常机器，优先明确黑名单正确性及弱读选择的副本。
      - 主库或备库持续 -4725，经常由 transfer 异常导致，优先排查 transfer 问题。
      - 删除租户后导致的 location 不存在，从而不断重试，需要明确对应线程是否没有及时退出。
      - 涉及复制表和普通表混合的路径，优先排查执行计划、SQL 层路由选择问题。
 2. 确认 tablet 状态，明确对应 ls_id 变化。

      1. 确认 tablet 状态。

        ```shell
        ## 1. 查看当前 tablet 。
        select * from __all_virtual_tablet_to_ls where tenant_id=xxxx and tablet_id=xxxx;

        ```

        ```shell
        ## 2. 查看 tablet 增删历史。
        select * from oceanbase.__all_virtual_tablet_to_table_history where tenant_id=xxxx and tablet_id=xxxx;

        ```
      2. 查询某个 tablet 的 Transfer 历史。

        ```shell
        select create_time,finish_time,src_ls,dest_ls,status from CDB_OB_TRANSFER_TASK_HISTORY where tenant_id = $tenant_id and tablet_list like "%$tablet_id%";

        ```
 3. 明确对应 LS 的 leader 变化。

   详见本文 **LS Location问题排查** 这一节。
 4. 查看 ObTabletLSService 日志。

   关键字：**[TABLET_LOCATION]** 。

## 其他异常

- 报错 -4664 。

  由于 `LS Location` 和 `Tablet Location` 都依赖 `inner sql` 访问 meta 表，当集群异常导致 `inner sql` 执行超时时，`Location Service` 会报错 -4664，符合预期。此时需要排查 `inner sql` 执行超时的原因。

  ![image003](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/202406214xlocationservice003.png)
 - 其他。

  如果排查发现 Location 持续存在真实异常，请联系 OceanBase 技术支持团队。

## 适用版本

OceanBase 数据库 V4.x 版本。

Previous

[OceanBase 数据库集群出现 ERROR 告警HAS UNFREE PTR 的原因和解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002397442)

Next

[OceanBase 数据库的三段式用户名格式与大小写敏感度](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000906440) ![有帮助](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) 咨询热线