tiflash 执行sql报region is unavilable

🪐 TiDB 技术问题 TiFlash
1

【 TiDB 使用环境】生产环境 or 测试环境 or POC
【 TiDB 版本】
v4.0.8
【遇到的问题】
执行某些聚合查询的SQL，会出现region is unavaileable
看了SQL的执行计划，都是sum group by，并且自动分配到tiflash上执行
【复现路径】做过哪些操作出现的问题
【问题现象及影响】
执行某个聚合计算的SQL，主要是sum group by，数据量大约300w，报region is availavle

同时tiflash的错误日志中，有以下的报错信息

2.09.11 22:08:38.041389 [ 329026351 ] CoprocessorHandler: grpc::Status DB::CoprocessorHandler::execute(): RegionException: region 1683245, message: NOT_FOUND: (while creating InputStreams from storage db_48.t_1858, table_id: 1858)
2022.09.11 22:08:42.969253 [ 329021362 ] DAGQueryBlockInterpreter: Check after read from Storage, region 1683240, version 1560, handle range [2799039587, 2799056972), status VERSION_ERROR
2022.09.11 22:08:42.974485 [ 329021362 ] DAGQueryBlockInterpreter: RegionException after read from storage, regions [1683240,], message: VERSION_ERROR, retry to read from local
2022.09.11 22:08:43.182245 [ 329021421 ] DAGQueryBlockInterpreter: Check after read from Storage, region 1683240, version 1560, handle range [2799039587, 2799056972), status VERSION_ERROR
2022.09.11 22:08:43.206093 [ 329021421 ] DAGQueryBlockInterpreter: RegionException after read from storage, regions [1683240,], message: VERSION_ERROR, retry to read from local
2022.09.11 22:08:46.022185 [ 329033088 ] DAGQueryBlockInterpreter: Check after read from Storage, region 1683240, version 1560, handle range [2799039587, 2799056972), status VERSION_ERROR
2022.09.11 22:08:46.022305 [ 329021933 ] DAGQueryBlockInterpreter: Check after read from Storage, region 1683240, version 1560, handle range [2799039587, 2799056972), status VERSION_ERROR
2022.09.11 22:08:46.040664 [ 329033088 ] DAGQueryBlockInterpreter: RegionException after read from storage, regions [1683240,], message: VERSION_ERROR, retry to read from local
2022.09.11 22:08:46.053768 [ 329021933 ] DAGQueryBlockInterpreter: RegionException after read from storage, regions [1683240,], message: VERSION_ERROR, retry to read from local
2022.09.11 22:09:02.994684 [ 329037158 ] pingcap.tikv: Failed4: Deadline Exceeded
2022.09.11 22:09:03.233701 [ 329037232 ] pingcap.tikv: Failed4: Deadline Exceeded

【附件】 相关日志及监控（https://metricstool.pingcap.com/)

若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。

2

补充一些信息：tiflash只有一个节点，主机CPU的使用率经常跑满，mem使用率大约50%

3

你检查一些表 、region的健康状况， 单独检查下2799039587, 2799056972
https://docs.pingcap.com/zh/tidb/dev/statistics#表的健康度信息

region 健康度可以通过grafana 查看

4

看一下你报错的时间点，节点资源使用情况，看看当时并发是多少，大概率跟你的资源使用有关系。

5

KV节点有报错日志吗？是否旧版本被GC了？

6

region的健康信息如何确认？可以表的健康度，有部分分区是在50左右，大部分都在70-100之间

7

regions 的 监控度：
登陆 grafana监控： PD —> Region health 版面
例： empty-region-count : 空region数据量，如果空region过多，需要merge

8

查一下 table_id: 1858 这个表是什么，看看对应的region所在kv节点， 在检查磁盘，如下：

你用的是SSD盘吗？建议你检查一些 tikv kv 节点的 磁盘，看磁盘时是否有坏块
这个集群曾经做过删除节点或者 kv 磁盘有过异常吗？

9

image
image828×265 19.6 KB

10

如果不做merge会引发这个region is unavailable的报错么？我手动执行这个SQL是偶尔能复现出现，偶尔失败下，不是一直失败

11

之前有下线过tiflash的节点，状态有变为Tombstone ，但是后来过了一晚，磁盘使用率下降后，又自动恢复了，看region所在的kv节点这个我还不太熟，怎么看？

12

KV 节点日志只有一些WARN：
[2022/09/13 16:52:51.508 +08:00] [WARN] [endpoint.rs:527] [error-response] [err=“Region error (will back off and retry) message: “peer is not leader for region 1676462, leader may Some(id: 1676465 store_id: 4)” not_leader { region_id: 1676462 leader { id: 1676465 store_id: 4 } }”]
[2022/09/13 16:52:51.509 +08:00] [WARN] [endpoint.rs:527] [error-response] [err=“Region error (will back off and retry) message: “peer is not leader for region 1694835, leader may Some(id: 1694838 store_id: 4)” not_leader { region_id: 1694835 leader { id: 1694838 store_id: 4 } }”]
[2022/09/13 16:52:51.940 +08:00] [WARN] [endpoint.rs:527] [error-response] [err=“Region error (will back off and retry) message: “peer is not leader for region 1672718, leader may Some(id: 1672721 store_id: 4)” not_leader { region_id: 1672718 leader { id: 1672721 store_id: 4 } }”]
[2022/09/13 16:52:51.943 +08:00] [WARN] [endpoint.rs:527] [error-response] [err=“Region error (will back off and retry) message: “peer is not leader for region 1676462, leader may Some(id: 1676465 store_id: 4)” not_leader { region_id: 1676462 leader { id: 1676465 store_id: 4 } }”]
[2022/09/13 16:52:51.943 +08:00] [WARN] [endpoint.rs:527] [error-response] [err=“Region error (will back off and retry) message: “peer is not leader for region 1694835, leader may Some(id: 1694838 store_id: 4)” not_leader { region_id: 1694835 leader { id: 1694838 store_id: 4 } }”]

13

空region 将近5000了，如果可以建议merge一下，参考这个

如何衡量 tidb 集群 空region 过多呢

14

空region对于整个集群的影响主要在哪儿？它和执行SQL报region is unavailable有直接联系么？

15

有点怀疑之前下线节点的时候 region信息没清理干净

1）确认是否是tiflash 遗留的：

select * from TIFLASH_TABLES where TABLE_ID=‘1858’; 如果有结果 那这个表就是tiflash中的表；

2）如果没结果就查kv的：

–查看到表名：
select * from TABLES where TIDB_TABLE_ID=‘1858’;

—查看到表的region id：
show table table_name regions;

—根据region id 查看region所在的节点：
select a.region_id,a.peer_id,a.store_id,b.address from tikv_region_peers a, tikv_store_status b where a.store_id=b.store_id and a.region_id=‘上面查的的region id’;

16

空regions 和 region is unavailable 应该没有直接联系

空region的影响：

image
image956×217 21.5 KB

17

1）确认是否是tiflash 遗留的：

select * from TIFLASH_TABLES where TABLE_ID=‘1858’; 如果有结果 那这个表就是tiflash中的表；

这个查询有结果，现有的存储是tikv和tiflash都存在，tiflash节点之前下线只是替换（物理机故障，扩容了一个节点，回收了物理机故障的节点），tiflash节点还是存在，并且提供服务

18

1、确认现在执行sql 统计信息关于这个表走的是 tiflash还是tikv?
2、表收集下统计信息；
3、再次执行sql ,看执行计划和 sql执行是否报错

还有一种可能就是：
小 region 太多， 在pd 调度的时候这个region 的确存在的，但是当你执行sql的时候 这个小region被merge 了， 这样之前的那个region 就找不到了

19

执行计划看tiflash和tikv都走了，表是个分区表比较大，有3年的分区，按天分区的，单天数据量400w条左右，这么大的表收集统计信息会很慢吧？之前也没敢手动收集过

20

目前发现tiflash的主机内存也有故障，计划先扩容一个tiflash节点，然后再下线掉当前的节点