Filter source是什么意思

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

  • 【TiDB 版本】:4.0
  • 【问题描述】:

Grafana中,pd-scheduler-filter source中一直存在replica-checker-store-1-health-filter一项,同时store1在运行过程中把大量leader迁移到了其他store。请问什么原因会导致replica-checker-store-1-health-filter呢?

1、store 1 上的 leader 大量的迁移至其他 store 可能是 store 1 当前比较繁忙,处于非健康状态。replica-checker-store-1-health-filter 的趋势也能从侧面反映这个问题。关于大量的从 store 1 中将 leader 迁移走可能是 store 本身负载比较高,网络通信等问题导致。具体可以查看下 pd leader 的 log 日志,tikv-details 的监控,看下是否能找到有效的信息~~

2、filter soure 面板的说明建议查阅官方文档:

https://docs.pingcap.com/zh/tidb/stable/grafana-pd-dashboard#scheduler

但是leader是从store1迁走的,为什么显示的store1是filter source呢?

存在 leader 从 store1 transfer 到其他节点的现象,建议从 pd leader 的 log 日志,tikv-details 的监控,看下是否能找到有效的信息。

replica-checker-store-1-health-filter 的趋势只是侧面反映出这个 store1 可能状态是有异常的,当 store1 作为 source 时,在进行 replica-checker 的时候,被过滤掉了。

replica-checker-store-1-health-filter 这个监控项本身和 transfer leader 的这个现象不是强关联关系。

日志中有类似这种内容:
[2020/10/15 13:07:59.017 +00:00] [INFO] [cluster.go:499] [“leader changed”] [region-id=54] [from=1] [to=2]
但也没发现更详细的信息(比如change的具体原因)。请问如何发现更多线索呢?

store1 掉 leader,建议看下 pd 到这个 store1 的网络通信情况,以及 store1 本身的情况比如负载,tikv-details 的 grafana 中 store1 的相关 metrics ~~

被 healthFilter 过滤掉有两种情况,1是tikv报busy 2是30分钟以上未上报心跳。这里看起来应该是有busy的情况,可以在TiKV页面确认下是否有busy的情况,以及busy的原因。

看了下server is busy一直是空的…cpu, memory这些metric也没有发现异常

请问server is busy都会监控哪些metric呢?

1、查看问题时间段的 tikv-details --> Error 监控面板整版的内容

2、如果方便,请根据下面的方式将问题时间段 12:30 ~ 13:30 的 tikv-details 以及 pd ,store1 的 node-exporter 监控导出:

可以的

mytidb-TiKV-Details_2020-10-20T08_41_15.031Z.json (1.5 MB) Tidb-Cluster-Node_exporter_2020-10-20T08_41_56.087Z.json (447.3 KB) mytidb-PD_2020-10-20T08_40_47.633Z.json (407.0 KB)

这次出问题的时间点大概是03:20-03:26 谢谢啦

1、当前是在做压测,并且使用的 rawkv 吗?

2、上传的 tikv 、pd 以及 node-exporter 的监控的时间段为 10 月 20 号 16:15 ~ 16:30 左右的时间段,并非上述截图中的 03:20 ~ 03:26

3、从已上传的监控信息可见,在 10月20 号 16:15 ~ 16:30 左右的监控中可以看到下面的信息 10.0.0.7:20160-store-1 的写入相关的指标,包括 commit log duration,propose wait,apply duration 都高于其他 store。建议检查下 10.0.0.7:20160-store-1 的 node-exporter 监控的 write latency 相关的指标。


4、某些指标也显示在压测期间 10.0.0.7:20160-store-1 处理数据的流量可能是高于其他 store,建议确认下业务行为是否有差异

5、压测时间段的 10.0.0.7:20160-store-1 的 tikv log 辛苦上传下

1、当前是在做压测,并且使用的 rawkv 吗? 对的

2、上传的 tikv 、pd 以及 node-exporter 的监控的时间段为 10 月 20 号 16:15 ~ 16:30 左右的时间段,并非上述截图中的 03:20 ~ 03:26 这个可能是服务器时区不一样:joy:

4、某些指标也显示在压测期间 10.0.0.7:20160-store-1 处理数据的流量可能是高于其他 store,建议确认下业务行为是否有差异 10.0.0.7一开始region leader比较多,这可能是流量大的原因?

下面的信息也请提供下,这里再分析看下:

3、从已上传的监控信息可见,在 10月20 号 16:15 ~ 16:30 左右的监控中可以看到下面的信息 10.0.0.7:20160-store-1 的写入相关的指标,包括 commit log duration,propose wait,apply duration 都高于其他 store。建议检查下 10.0.0.7:20160-store-1node-exporter 监控的 write latency 相关的指标。

5、压测时间段的 10.0.0.7:20160-store-1 的 tikv log 辛苦上传下

之前的log被覆盖掉了,我试着重新复现了下问题。

看了下 10.0.0.7:20160-store-1 出问题时段的write latency确实比其他节点高了不少(2s VS 20-30ms)。这个会导致节点状态变成unhealthy吗?tikv和pd的源码中好像没搜到监控disk latency的代码段,而是根据heartbeat响应是否超时来决定的

mytidb-PD_2020-10-26T10_36_19.368Z.json (471.7 KB) mytidb-TiKV-Details_2020-10-26T10_39_25.805Z.json (1.7 MB) Tidb-Cluster-Node_exporter_2020-10-26T10_37_57.922Z_10.0.0.7.json (504.1 KB) Tidb-Cluster-Node_exporter_2020-10-26T10_38_39.088Z_10.0.0.6.json (514.3 KB) Tidb-Cluster-Node_exporter_2020-10-26T10_39_07.408Z_10.0.0.9.json (507.3 KB) 10.0.0.7_tikv.log (206.8 KB)

1、在 tikv 中 raft 心跳是通过 raftstore 发送的,raftstore 发送的 raftlog 信息需要落盘,当磁盘出现卡顿时,心跳会因为发送不出去,而触发 raft 选举。

https://docs.pingcap.com/zh/tidb/stable/massive-regions-best-practices#raftstore-的工作流程

2、建议确认下 store-1 的服务器磁盘性能,当前服务器使用的是 SSD 还是 Nvme ?以及是否存在流量不均衡的情况,比如 store-1 承担的流量明显多于其他 store ~

好的 谢谢~

1、在 tikv 中 raft 心跳是通过 raftstore 发送的,raftstore 发送的 raftlog 信息需要落盘,当磁盘出现卡顿时,心跳会因为发送不出去,而触发 raft 选举。

心跳发不出去会在log或者grafana里有记录吗?

磁盘用的全都是SSD。store1一开始ycsb load阶段的流量就比较多(region leader也多)。

监控可见 \rtikv 的 cpu 核数只有 4C ,在压测期间,10.0.0.7除磁盘延时高外,服务器的 load 也比较高:


10.0.0.9 服务器 load:

心跳发送在 grafana 和 tikv log 中没有特别直观的展示,但是可以通过下面的信息来进行推断:

1)在 10.0.0.7 的 store 日志中,有大量的 raft 选举的信息,如下:

[2020/10/26 10:23:24.027 +00:00] [INFO] [raft.rs:1003] ["received a message with higher term from 20"] ["msg type"=MsgRequestVote] [message_term=10] [term=9] [from=20] [raft_id=19] [region_id=18]
[2020/10/26 10:23:24.027 +00:00] [INFO] [raft.rs:783] ["became follower at term 10"] [term=10] [raft_id=19] [region_id=18]
[2020/10/26 10:23:24.027 +00:00] [INFO] [raft.rs:1192] ["[logterm: 9, index: 83123, vote: 0] cast vote for 20 [logterm: 9, index: 83123] at term 10"] ["msg type"=MsgRequestVote] [term=10] [msg_index=83123] [msg_term=9] [from=20] [vote=0] [log_index=83123] [log_term=9] [raft_id=19] [region_id=18]

2)可以到其他 store 上过滤下压测时间段的 region 18 的相关信息,看下 region 18 详细的选举信息。

感谢!请问这个load是根据什么计算的呀

这个 load 就是服务器的负载,非数据库软件的负载