是 raft 心跳的流量吧

看起来unsafe recover 导致索引和数据不一致了，admin check recover 或者重建下索引应该就可以了。

666，都是牛人

我这里。 [image]

172.18.234.83在 9 点 30 左右夯死用户重启过一次，11 点到 15:44的问题经过排查推测还是172.18.234.83内核夯导致的，因为多个日志（系统 message，tikv log，rocksdb log，raftrockslog） 都在 09:33 到 17:28 之间没有任何日志写入，tikv 监控中发现该实例压力很小，因为 compaction 文件积压导致 write stall，应该也是卡在了内核层无法写文件。 该问题需要事故时的堆栈信息和火焰图来实锤，只能等下次复现后通过 dashboard 的 profiling 抓取相关信息再定位了。

log.tar.gz (275.9 KB) dmseg日志和 message 日志

可以考虑降低 vm.dirty_ratio 的比例到一个适合业务负载的值

问题期间的监控：https://clinic.pingcap.com:4433/diag/files/?uuid=d8dabe9be6db24f6-6631859ed0e0b6e1-89f55096c7880ac6

看起来是系统夯死了吧，sar -B 事发时间段的数据贴下

请提供下以下信息： 1./var/log/kern.log oom重启前后的日志 2.问题时间段，该机器上的其它进程正常么？ 3.故障前后的监控导出看下吧，TiDB 的和 Node_exporter 的

主要是看下事发当时该节点的流量情况、访问报错的信息，操作系统内核日志是不是发错了，tidb error 有报错么

tidb err 和系统内核日志排查下呢，以及节点流量监控看下

tidb是无状态的，oom 后会快速拉起，看日志也是快速拉起来的，也有 cop 请求，你说的慢是指的什么？

oom可能是某几条 sql 使用内存过多导致，也有可能是某些消耗内存的 sql 并发高导致

kubectl exec -it 登录到指定容器里应该是可以找到未被清理的日志的

666，元宵版发布，

那就通过一条不一致的记录，查询下 pump、drainer 日志，先看下是在哪个步骤丢失的把，然后再去对应的日志里看下丢失的原因

建议： 1.建议做一次上下游数据校验，确认下数据不一致范围 2.下游丢失的数据，从 pump、drainer 的日志里找下，看在哪一层丢掉的

如果丢数据前后没有不规范的扩容 tidb 、dump操作，那看下是否跟这个有关系，https://docs.pingcap.com/zh/tidb/v4.0/tidb-binlog-overview#注意事项。 建议主从集群做一次全量校验，确认下数据不一致范围。