少量不需要处理
大量出现时需要根据 table id 综合业务请求来分析
是否有读或者很慢的写请求
2、 [FAQ] region not exist but not tombstone
可以说明这个 peer split 进行得比较晚，一般属于正常现象，不需要特殊处理
1）如果这个信息的量很深，属于正常调度，可以忽略
2）可以通过日志和监控来定位，如果日志中出现大量的这种信息，需要查看监控是不是集群负载太高。如果集群负载很高了，可能需要加节点来提高集群的性能
4、 [FAQ] request to underhook engine failed
具体原因需要看其他日志中打印的 error 的类型.
https://github.com/pingcap/kvproto/blob/1082c388cb012ce4be423257f72a8ea2e518d7ac/proto/errorpb.proto#L53-L64)https://github.com/pingcap/kvproto/blob/1082c388cb012ce4be423257f72a8ea2e518d7ac/proto/errorpb.proto#L53-L64
5、 [FAQ] handle ready 1 committed entries
1）查看盘是否变慢
2）查看 Apply 线程的监控，是否 Apply 线程使用率过高
3）查看是否有明显的热点
4）若没有明显的热点，可以修改监控公式查看每个 Apply 线程的使用率，是否出现线程负载不均衡的现象
6、[FAQ] handle 6 pending peers include 6 ready, 1 entries, 6 messages and 0 snapshots
同 https://asktug.com/t/topic/37379 ，查看 Raftstore 线程
1）查看是否有 TiKV 挂掉
2）查看 TiKV 之间的网络是否有异常
8、 [FAQ] batch_raft send response fail
参考 https://asktug.com/t/topic/37381
9、 [FAQ] concurrent map read and map write
上报 BUG
10、 tikv 报错： [“failed gc”] [err=“Engine(Request(message: \”stale command\”))”]
无影响，忽略
无影响，忽略
12、 tikv log：tikv scheduler busy
scheduler-pending-write-threshold = “100MB”
13、 tikv log 出现日志：region not exist but not tombstone
无影响，忽略
14、 tikv error log ：”peer is not leader” not_leader
数量少是正常的，如果大量掉 leader，可能是 channel full、磁盘 io 100% 了等，需要查看监控和具体日志，然后来定位是不是需要升级配置
15、 tikv log 出现以下日志：[tikv:9003]TiKV server is busy[try again later]
1. raftstore is busy: 可能是由于存在写入热点或下层写入太慢，观察具体监控和日志来确定
2. coprocessor full: coprocessor 任务堆积，可能是由于存在读热点或下层读取太慢，可以通过调整 readpool.coprocessor.max-tasks-per-worker-normal, max-tasks-per-worker-high, max-tasks-per-worker-low 缓解
3. scheduler is busy: scheduler-pending-write-threshold = “100MB”
16、 tikv error log：get snapshot failed
通常属于正常现象，若大量出现导致 region is unavailable 等问题则考虑 Raft Engine 出现了某些问题，需要进一步查看监控和日志定位
17、 tikv info log ：mark store’s regions need be refill
1）查看 TiKV 是否挂掉或已下线
2）确认 TiDB 与 TiKV 之间的网络是否有异常