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

基础知识

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

为了提高访问性能，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 。

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

   2. 查看历史 leader 。

      无主排查详见：V4.0 无主问题排查手册

      ## 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;
      

      ## 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;
      

      或查看日志：

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

      ## 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 的正确性。

      

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 状态。

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

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

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

      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 执行超时的原因。

  

• 其他。

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

适用版本

OceanBase 数据库 V4.x 版本。