TiKV节点出现大量的TiKV_raft_log_lag的问题

seiang · 2022 年1 月 18 日 02:57

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
生产环境 v5.0.3

【概述】场景+问题概述
今天凌晨，tikv节点出现大量的TiKV_raft_log_lag的报警，说明 Follower 已经远远落后于 Leader，Raft 没法正常同步了，导致整个集群延迟非常突增，业务写入时间在4min左右

当时空region比较多，临时调大了merge-schedule-limit、max-merge-region-keys、max-merge-region-size之后恢复正常

目前已经恢复正常，监控也恢复正常，但是 [Prometheus]中还是有一个节点TiKV_raft_log_lag比较大的问题，感觉Prometheus的数据没有更新过来

【背景】做过哪些操作
【现象】业务和数据库现象
【业务影响】
【TiDB 版本】
v5.0.3
【附件】

报警节点的TiKV日志如下：

相关日志和监控
 tikv.log_tar.gz (10.1 MB)

TiUP Cluster Display 信息
TiUP Cluster Edit Config 信息
TiDB- Overview 监控

对应模块日志（包含问题前后1小时日志）

spc_monkey · 2022 年1 月 19 日 02:14

先说一下集群整体状态？（或者说提供一下慢日志信息），下面这个帖子有导出监控的方式：https://asktug.com/t/topic/37248，目前提供的信息，只是现象，没有信息可以排查的

seiang · 2022 年1 月 19 日 04:22

如下是慢查询，正常情况下该insert操作也就3ms左右，现在18s

执行计划：

如下是tikv-details监控面板的导出快照
tidb–TiKV-Details_2022-01-19T04_15_18.114Z.json (3.0 MB)

spc_monkey · 2022 年1 月 19 日 05:50

1、你的是在做什么操作吗？看集群的region 数量在不断的减少
2、你导出的监控少很多内容，建议你重新给导出一份 PD/overview/tikv0detail 的监控

spc_monkey · 2022 年1 月 19 日 05:52

如果现在问题还存在，可以先调低一些 scheduler limit（pd-ctl 里 config show all 里的几个 limit ，调小一些）

seiang · 2022 年1 月 19 日 06:32

问题是发生在1月18日凌晨00:00~00:40，1月17日上午的时候，drop了几张历史大表；所以region数据在减少；

如下是PD/overview/tikv0detail 的监控：
tidb–Overview_2022-01-19T06_29_35.029Z.json (792.3 KB) tidb-PD_2022-01-19T06_27_16.048Z.json (208.2 KB) tidb–TiKV-Details_2022-01-19T06_24_58.401Z.json (2.0 MB)

seiang · 2022 年1 月 19 日 06:48

以下面的这个导出的监控信息为准
监控信息.rar (2.3 MB)

目前从 [Prometheus]看，有个tikv节点的 TiKV_raft_log_lag指标数据一致都是10240

seiang · 2022 年1 月 20 日 04:11

@spc_monkey 大佬，协助帮忙看看，有分析结果反馈一下，谢谢

Billmay表妹 · 2022 年1 月 20 日 04:39

着急的话，可以在：我的团队-我的主题-进行加急一下

spc_monkey · 2022 年1 月 20 日 07:27

你导出的监控都是这样的，我没法看（你需要等他都打开之后，再导出，不然导出的信息都是空的）

seiang · 2022 年1 月 20 日 07:36

你好，以这个里面的监控为主，这个里面的监控是完整的

spc_monkey · 2022 年1 月 20 日 07:48

按我理解你有2个问题：1、这次写入慢的问题 2、raft—log-lag 的问题

seiang · 2022 年1 月 20 日 08:00

是的，就是这两个问题

spc_monkey · 2022 年1 月 20 日 08:06

第一个问题，应该是调度导致的 store 4 太忙，导致对应时间的 store 处于了一个不太可用的状态（un reachable）：这里说的调度都是 merge 的调度，所以和你说的 drop 操作其实匹配的「我需要你看看 pd-ctl config show all 的结果）

spc_monkey · 2022 年1 月 20 日 08:09

第二个问题：raft-log 一直是 10240 的问题，嘿嘿，我也不知道，不过，我建议你根据 pd 的日志（或 tikv 的日志）找到对应的 region id，然后用 pd-ctl region 命令，看一下这个 region 的状态

spc_monkey · 2022 年1 月 20 日 08:10

或者你提供我一下这2个日志，然后告诉我一个 region id（好像不用，tikv 日志里应该有记录）
我要的信息：1、pd-ctl 里面的 config show all 的配置 2、pd/tikv（对应 store）的日志

seiang · 2022 年1 月 20 日 08:31

tikv.log_26.tar.gz (3.1 MB) tikv.log_tar.gz (10.1 MB)
pd配置.txt (5.7 KB)
你好，附件tikv.log_tar.gz是当时问题tikv节点的日志，而tikv.log_26.tar.gz是目前26这个tikv节点的日志，就是这个节点，raft-log 一直是 10240

seiang · 2022 年1 月 21 日 06:58

@spc_monkey 大佬，分析的咋样，有结果吗

spc_monkey · 2022 年1 月 21 日 08:14

你只给我这些信息没用的：
1、你的 merge limit 我看好像调大了，可以适当减少一些，比如恢复到默认值
2、关于 log lag 的问题，我这边是需要找到一个具体的 region id 来进行排查的：
2.1 用 pd-ctl region check 命令找到有问题的 rengion 同时看看 pd 监控下的 region health 监控面板
2.2 找到 region id 之后，需要 grep regionid pd.log 和。grep。regionid。tikv.log (*注：这里的 tikv 的 log，是发生 lag的 store 的日志，怎么找到这个 storeid，上面的 pd-ctl region 命令会有相关信息）

system · 2022 年10 月 31 日 19:25

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。