TiDB升级后调度超时,异常region增多

【集群版本】 v3.0.12升级至v4.0.16
【复现路径】
一个数据量较大的集群(数据量80TB左右,120个左右的tikv实例)进行版本升级
升级前期较为顺畅,大约1min左右可以完成1个实例的evict leader,但是还剩30多个实例时leader转移开始卡慢,出现600s超时的问题,于是手动对应节点的实例进行了restart以便加速升级速度,之后正常跑完升级流程。
【遇到的问题:问题现象及影响】
升级完成后,查看监控发现pd调度界面显示的异常peer开始增多,见下图。


经查看pd leader的日志以及手动测试发现,常规的leader transfer operator和remove peer等极大概率超时,下图为我随机选取一个operator的执行日志:
首先是pd leader展示的超时流程:

然后是目标store展示的此region相关的操作:

至"deleting applied snap file"之后截止,也不知道是卡住了还是日志就展示这么点东西。
当前由于磁盘使用率较高,因此我进行了扩容,但是发现新节点的均衡速度极其缓慢。
【我的猜测以及我问题】
我个人猜测可能是强制重启带来了较大范围的region peer置换,这种置换的速率较低引发了extra-peer和learner-peer的堆积。
请问下是否有什么办法来处理上述的operator超时问题?从而加快region的调度速度,只调整region调度参数目前只能导致更多的堆积而无法对加速起到实质作用了。
【其他附件】
pd当前配置:

» config show
{
  "replication": {
    "enable-placement-rules": "false",
    "location-labels": "host",
    "max-replicas": 3,
    "strictly-match-label": "false"
  },
  "schedule": {
    "enable-cross-table-merge": "false",
    "high-space-ratio": 0.75,
    "hot-region-cache-hits-threshold": 3,
    "hot-region-schedule-limit": 4,
    "leader-schedule-limit": 8,
    "leader-schedule-policy": "count",
    "low-space-ratio": 0.8,
    "max-merge-region-keys": 200000,
    "max-merge-region-size": 20,
    "max-pending-peer-count": 16,
    "max-snapshot-count": 3,
    "max-store-down-time": "30m0s",
    "merge-schedule-limit": 16,
    "patrol-region-interval": "100ms",
    "region-schedule-limit": 256,
    "replica-schedule-limit": 64,
    "split-merge-interval": "1h0m0s",
    "tolerant-size-ratio": 0
  }
}
» scheduler show
[
  "label-scheduler",
  "balance-region-scheduler",
  "balance-hot-region-scheduler",
  "balance-leader-scheduler"
]

scheduler-limit参数是限制operator的产生速度,有个pd-ctl store limit 限制 operator的消费速度,可以试试加大些。 另外感觉可以先把leader hot-region scheduler先停掉,降低调度量和冲突

补充一个问题:
“max-snapshot-count”: 3在过pd配置的时候注意到这个参数是我无法理解的。
查了很多资料还是没发现明确的解释,代码里好像说是pd cluster config的snapshot,但是放在schedule部分很迷惑。
这个snapshot和tikv日志中的snapshot有什么关联呢?

region迁移时先生产region的snapshot 快照文件然后发送到目标tikv,之后再从这个快照追raftlog

目前由于extra-peer积压,我把store limit all调整到了200的上限并降低了region schedule limit的值以期能够迅速消费,这块算调整过了

感谢解释,我调整一下,我看新版本的默认值是64,4.0还是3,我想调整为64看看效果。

磁盘IO CPU 网络 忙吗

补充一个问题:
我在本文中补充的operator执行日志显示add peer的操作超时失败了,而对应store显示"deleting applied snap file"之后就没有这个region的日志了,正常情况下是否还应该有类似“snap file deleted”的日志,是否是删除snap file超时导致的operator超时。
补充:看了下snap文件夹里没东西,应该是正常删除了

磁盘 cpu使用率20% -30%之间徘徊,不算繁忙,网络的inbound/outbound也都不到20mb/s

你这个扩容是扩的文件系统 还是增加的tikv? 这个是在发现大量extrapeer后做的吧? 强制重启tikv 也就是Leader 选举切换的问题,应该不会造成region的迁移, 在tikv达到max store down time后才会自动再其他节点补副本。要是光升级完没做其他操作就开始大量region迁移 感觉是不是新版本算法变了 ,看看leader /region 均衡的监控 还有score等差异大吗

扩容的tikv实例,是在extra-peer量大之后做的。
除了升级时强制重启正在evict leader的实例之外没有其他操作。
可能是你说的,因为迁移之后的leader数都没有之前均衡了。


监控中region score发生明显升高的起始点是昨天下班前我调高了region-schedule-limit的参数,调整原因是看到extra-peer开始升高想要加速完成。

当前的4.0.16版本还调整不了

感觉这个状态现在只能慢慢等了

找到如此大规模产生extra-replica的原因了,是这个集群以前从ansible转到tiup管理时,tikv的sync-log参数未录入,所以升级时没有关注,现在发现集群120多个实例中有55%的实例都有sync-log=false的设置,猜测是以前为了加速而设置的。
这个问题导致目前如此大规模的region调度。
至于之前的store score算分问题,把low/high space ratio调高之后就恢复了。
目前主要的问题点就是几乎所有类型的operator都超时严重(例如leader transfer/remove-extra-replica/balance region/merge region等),实际追踪了一个remove-extra-replica的删除操作,发现tikv日志显示peer已经在当前store上删除了,但是pd日志显示schedule 10m超时,见下面两幅图:



然后看了下pd heartbeat P99都是2s,感觉append log entries堵了。

现在把region/replica schedule limit调整的非常小,然后逐一设置reject leader并重启sync-log=false的节点,但是由于leader转移的很慢,这个流程会很漫长了。
请问下目前heart beat这种全面超时是否有介入办法?

:+1: 怎么发现是sync-log参数影响的?

目前只能暂归于这个原因,问题还没法解决。
“强制重启tikv 也就是Leader 选举切换的问题,应该不会造成region的迁移”
你回复的这句给了提示 :handshake: ,简单过了一下raft的paper我们想只要正常进行sync log那只需要常规的同步就能维护好数据一致性了,于是拉了一下dashboard里的诊断报告发现结果里显示有很多sync-log为not false的警告,于是实际看了下很多tikv的配置都是false,只是tiup edit里没展示,应该是后期tiup扩容的都是true,以前的都是false。

忘了从哪个版本开始了默认这个参数是true而且已经不能修改了,3.x的tidb还没玩过

目前问题已经解决掉了:
1.重启pd集群后operator超时现象和心跳达限会短时间内恢复,但是5-6个小时后会重新开始出现。
2.最终修改了pd的一个参数trace-region-flow=false,此参数必须reload pd集群生效,因此建议使用tiup edit后reload pd集群,保险起见在pdctl中也预先config set一下。
3.tikv sync-log参数由古早时期ansible管理时设置,引入tiup后未统一过。需要将meta.yaml中的imported: true项删除,保险起见删除ansible-imported-configs和config-cache目录后reload集群,使用统一管理的全新版本默认参数启动集群并升级。