TiDB_schema_error问题

🪐 TiDB 技术问题
,
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】v5.4.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】

集群v5.4.0，GC时长10min，默认值。

  1. 收到告警：TiDB_domain_load_schema_total 和TiDB_schema_error
  2. 官网的解决思路：
  • 规则描述：TiDB 在一个 Lease 时间内没有重载到最新的 Schema 信息。如果 TiDB 无法继续对外提供服务，则对上述问题报警。
  • 处理方法：该问题通常由于 TiKV Region 不可用或超时导致，需要看 TiKV 的监控指标定位问题。

  1. 确认tikv节点和机器正常，网络通畅。推测是region不可用的问题。发现来自节点store1的请求比其他的都慢，时间也吻合。

  2. 在问题开始时间点，在store1发现信息：
    [2024/12/19 17:36:47.816 +08:00] [ERROR] [split_observer.rs:143] [“failed to handle split req”] [err=“"no valid key found for split."”] [region_id=230725]

[2024/12/19 17:39:08.633 +08:00] [WARN] [endpoint.rs:606] [error-response] [err=“Key is locked (will clean up) primary_lock: 7480000000000000115F7280000000000289AA lock_version: 454715283501481993 key: 7480000000000000115F7280000000000289AA lock_ttl: 3001 txn_size: 1 min_commit_ts: 4547
15283501481994”]

查看key信息：

 tiup ctl:v5.4.0 pd -u http://pd:2379 region key 7480000000000000115F7280000000000289AA 

{
  "id": 59792,
  "start_key": "6F67772E6E6D7264FF5F656E636F64655FFF72617069646A736FFF6E322E6F626A6563FF74732E7A6A2D6F62FF73746573742D325FFF6664396166353566FF3463313234316436FF6566303565363635FF6662613664373562FF2D3231312D6F626AFF6563742E74657374FF2D32373500000000FB",
  "end_key": "7480000000000000FF195F728000000000FF09C9940000000000FA",
  "epoch": {
    "conf_ver": 19669,
    "version": 213
  },
  "peers": [
    {
      "id": 230454,
      "store_id": 1,
      "role_name": "Voter"
    },
    {
      "id": 230660,
      "store_id": 3,
      "role_name": "Voter"
    },
    {
      "id": 230693,
      "store_id": 18,
      "role_name": "Voter"
    }
  ],
  "leader": {
    "id": 230454,
    "store_id": 1,
    "role_name": "Voter"
  },
  "written_bytes": 2781,
  "read_bytes": 563171,
  "written_keys": 33,
  "read_keys": 3593,
  "approximate_size": 56,
  "approximate_keys": 75312
}

分别查看region 230454、230660、230693，均没有信息。推测是region已经被分裂或合并了，但是相关的lock信息没有被清理，导致阻塞了后续请求。

查看region id= 59792，发现里面都是mysql库下的系统表（stats_histograms、tidb、user等等）。推测和系统元数据损坏或者无法识别有关。

5.尝试重启节点，锁信息仍在、并未被清理。是否还有其他处理方式？

2

确认一下 Store1 的延迟高原因，需要检查一下 Store1 的 TiKV 的监控，是否异常指标。

3

这个节点所在机器的网络正常、访问负载比较低，无热点，CPU、内存、IO等资源情况都是正常的，而且很空闲

4

破案了，经过反复确认是业务侧使用rawkv接口去写入这个集群，导致元数据混乱，出现原TiDB集群无法解码的内容。进而出现这些问题。

2 个赞