Coprocessor 错误,好多not_leader错误，是什么原因呢，怎么解决？

🪐 TiDB 技术问题
,
1

【TiDB 使用环境】生产环境
【TiDB 版本】V8.5
【部署方式】云上部署（火山云）
【操作系统/CPU 架构/芯片详情】
【机器部署详情】CPU大小：各节点8 (16 vCore)/内存大小：各节点30G/磁盘大小：TIkv 三节点，各节点5TB
【集群节点数】10
TiDB Dashboard集群诊断生成的报告，
Coprocessor 错误总数量
收起 512
|-- tikv_coprocessor_request_error_total_count 21.1.2.200:7,not_leader 140
|-- tikv_coprocessor_request_error_total_count 21.1.2.202:7,meet_lock 99
|-- tikv_coprocessor_request_error_total_count 21.1.2.201:7,not_leader 93
|-- tikv_coprocessor_request_error_total_count 21.1.2.202:7,not_leader 77
|-- tikv_coprocessor_request_error_total_count 21.1.2.201:7,meet_lock 63
|-- tikv_coprocessor_request_error_total_count 21.1.2.200:7,meet_lock 35
|-- tikv_coprocessor_request_error_total_count 21.1.2.202:7,epoch_not_match 4
|-- tikv_coprocessor_request_error_total_count 21.1.2.201:7,stale_command 1

2

生产中少量的not_leader告警，我们是直接忽略，tidb会自己重新路由，对业务没有影响。如果是非常大量的，比如上万那可能意味部分tikv实例出现抖动了，具体告警原因可以看下这个介绍：
TiDB server 根据自己的缓存信息访问 TiKV 的 Region leader。如果 Region leader 有变化或者当前 TiKV 的 Region 信息与 TiDB 的缓存不一致，就会产生 Region 缓存错误。

3

日志信息有点少啊

4

集群的 Region Leader 分布或路由有异常。

5

好呀好呀，谢谢~

6

这是生成的集群诊断报告关于 Coprocessor部分的,这个问题并不是一直都有，其他告警信息基本没大有了哦

7

少量的缓存失效是正常的吗？

8

还有其他日志信息吗

9

我的理解是可以设置缓存窗口大小吧

10

个人理解是正常的，毕竟是分布式架构，所有tidb节点都可以操作tikv。

11

一直报错吗？leader调度太频繁，可能是资源问题，CPU网络等等。主要就是心态过期了

12

缓存会有定期刷新的时间？

13

这周看了下就没有相应的报错了

14

不是持续的报是正常的。

15

没有一直报错应该没啥问题了

16

not_leader 常见错误提示，本地缓存路由信息未及时更新，导致发到了follower副本。会重试，一般无需关注。但是频繁出现需要查下leader切换是不是很频繁，并查明原因。
meet_lock 排查是否有死锁，产生死锁的语句 是否需要优化。是否有长事务？
epoch_not_match/ stale_command 可能和本地缓存有关
建议多看下日志。

17

看哪些日志，通过哪些报表判断？

18

关于meet_lock排查死锁的语句，整理了一下：
– 查看当前锁等待
SELECT * FROM INFORMATION_SCHEMA.DATA_LOCK_WAITS;

– 查看整个集群的死锁历史
SELECT * FROM INFORMATION_SCHEMA.CLUSTER_DEADLOCKS;

– 查看整个集群的进程列表
SELECT * FROM INFORMATION_SCHEMA.CLUSTER_PROCESSLIST;

– 查找运行时间过长的活跃事务
SELECT
ID, – 事务ID (start_ts)
START_TIME, – 开始时间 (物理时间)
TIME_TO_SEC(TIMEDIFF(NOW(), START_TIME)) as ‘运行时长(秒)’,
STATE, – 状态 (Idle/Running/LockWaiting)
DB, – 数据库
USER, – 用户名
SESSION_ID, – Session ID
CURRENT_SQL_DIGEST_TEXT – 当前正在执行的SQL文本
FROM INFORMATION_SCHEMA.CLUSTER_TIDB_TRX
ORDER BY START_TIME; – 最早的排在前面，最可能是长事务

– 定位阻塞ID，kill
SELECT
l.key, – 发生锁冲突的key
l.trx_id AS ‘被阻塞的事务ID’, – 正在等待的事务
l.current_holding_trx_id AS ‘阻塞者事务ID’, – 拿着锁不放的事务 (目标)
trx.SESSION_ID, – 需要kill的会话ID ★
trx.START_TIME, – 阻塞事务的开始时间
trx.CURRENT_SQL_DIGEST_TEXT, – 阻塞者当前执行的SQL
trx.USER,
trx.DB
FROM
INFORMATION_SCHEMA.DATA_LOCK_WAITS l
JOIN
INFORMATION_SCHEMA.CLUSTER_TIDB_TRX trx
ON
l.current_holding_trx_id = trx.ID – 关联阻塞者的事务ID
ORDER BY
trx.START_TIME;

– TiDB 的死锁检测机制会自动发现并强制回滚其中一个事务，无需人工干预

19

可能是由大事务引起的，当一个事务需要更新大量数据时，它会在涉及的数据行上加上锁，建议拆分事务， 将DELETE或 UPDATE`操作拆分成多个小事务

20

关于epoch_not_match少量错误可以忽略的
– 检查 TiKV 节点是否在线或者监控面板查看
SELECT * FROM INFORMATION_SCHEMA.TIKV_STORE_STATUS;

– 检查 Region 健康度
SELECT
COUNT(DISTINCT p.REGION_ID) AS ‘总Region数’,
COUNT(DISTINCT CASE WHEN p.IS_LEADER = 1 THEN p.REGION_ID END) AS ‘有Leader的Region数’,
COUNT(DISTINCT CASE WHEN p.IS_LEADER = 0 THEN p.REGION_ID END) AS ‘有副本但非Leader的Region数’
FROM
INFORMATION_SCHEMA.TIKV_REGION_PEERS p;

– 查找所有没有 Leader 的 Region：
SELECT
r.REGION_ID,
r.DB_NAME,
r.TABLE_NAME,
r.APPROXIMATE_SIZE,
r.APPROXIMATE_KEYS,
GROUP_CONCAT(p.STORE_ID) AS ‘副本所在Store’
FROM
INFORMATION_SCHEMA.TIKV_REGION_STATUS r
LEFT JOIN
INFORMATION_SCHEMA.TIKV_REGION_PEERS p
ON r.REGION_ID = p.REGION_ID
WHERE
NOT EXISTS (
SELECT 1
FROM INFORMATION_SCHEMA.TIKV_REGION_PEERS
WHERE REGION_ID = r.REGION_ID
AND IS_LEADER = 1
)
GROUP BY
r.REGION_ID, r.DB_NAME, r.TABLE_NAME, r.APPROXIMATE_SIZE, r.APPROXIMATE_KEYS;