【源码学习】TiKV node Raft catch up process

[TiDBerrrrrrrr (Ti D Ber D Pp Hk C9 G)]

【 TiDB 使用环境】生产环境 /测试/ Poc
N/A
【 TiDB 版本】
8.1.1
【复现路径】做过哪些操作出现的问题

1. 设置一个大的集群，有不断的写traffic进这个集群
2. 把max-store-down-time设置为很大( > 24 小时）
3. 将一个store shutdown 30分钟/1小时/2小时. shutdown的时候，PD会加scheduler, evict leader scheduler on this store. 所以这个store之后就没有leader了，但还有region
4. 重新启动这个host. 启动的时候，会把PD上面evict leader schedule 给删了

【问题】
大家好，我想了解一下tikv 在shutdown之后，有没有一个metric或者log 告诉我们这个node是不是已经catch up的。这里涉及到几个小问题

1. TiKV对于catch-up的定义是什么? 是不是有一个阈值可以设置，只要follower和leader之间的commit log在阈值内，就算是catch-up了。
2. 从PD的角度来看，PD会只在TiKV catch-up之后才把这个store标记为UP吗？

我花了一些时间去阅读源码(store.rs#start_system)。我的理解是当一个store起来的时候，他会异步去同步raft log，并且给PD发心跳。从PD的角度来看，不管这个store有没有最新的raft log，只要发了心跳，它的状态都会是UP。
我也有看到 TiKV_raft_log_lag这个警报，它看起来很像是我的需要的，但看代码，好像这个是检测peer的lag，而不是他自己本身的lag？
我有遗漏什么东西吗？

[有猫万事足]

@TiDBerrrrrrrr

从PD的角度来看，不管这个store有没有最新的raft log，只要发了心跳，它的状态都会是UP。

你这个理解是没问题的。

@TiDBerrrrrrrr

我也有看到 TiKV_raft_log_lag这个警报，它看起来很像是我的需要的，但看代码，好像这个是检测peer的lag，而不是他自己本身的lag？

我理解catch-up这件事是每个region自己的事。除非整个store的region都是leader。否则store级的catch-up这是个挺理想化的事。

[TiDBerrrrrrrr (Ti D Ber D Pp Hk C9 G)]

感谢感谢🙏 明白了，所以这个catch up不值得纠结了！