tidb集群莫名失联(疑似时间不同步引发)

[realcp1018]

【 TiDB 使用环境】生产环境
【 TiDB 版本】3.0.19
【遇到的问题：问题现象及影响】
早上5点多收到告警，显示一个集群的所有pd-server集体失联，尝试重启集群(失败)和重启服务器都无用。
【资源配置】48c189m物理机，3节点pd集群。
【附件：截图/日志/监控】
早5:08左右，leader发生选举，选举后pd_PD_6依然为leader：

随后发生长约51min37s的load region流程，直到此流程完毕集群才恢复（5:08-6:58包含：故障发生->收到告警->告警处理->最终恢复 的全部时间，期间有重启集群和服务器的操作）：
load region过程中日志全部是上图中的“region is stale”报错。

初步怀疑是时间同步问题导致的BUG，现在问题有3：

1. 问题是否由时间同步问题引发？如果不是还可能是什么原因？需要什么其他资料探寻？

2. 如果是时间同步问题那么3.0.19之后的版本是否有修复？(因为时间不同步这种事情总会发生，即便有时间同步服务存在)

3. region很多时load region的流程过长，之后的版本是否有优化？

之后尝试进行版本升级，重启pd过程中依然会出现长时间的load region导致重启pd失败，目前只能等load完毕后再次尝试一下，集群处于不可用状态。
问题：
4. 现在如何实现平滑升级，以往的3.0.19升级并未遇到此类超长load耗时。

[Billmay表妹 (表妹)]

尽可能升级高版本，低版本大家基本上大家也都不用了
没有一样的版本很多问题无法复现
会影响你解决问题的效率
另外，很多低版本的问题高版本都已经解决了~
所以有可能你很多求助的问题答案都是： BUG ，升级高版本即可解决问题。

[我是咖啡哥]

3.0啊，版本确实老。那时候还没学tidb呢

[realcp1018]

刚才尝试升级，启动过程中pd-leader持续load region，且包含一些load retry操作。3个多小时都没完，使用旧的pd bin文件回退后，集群状态正常了，但是所有账号好像都丢了…root都登不了
补充：
用户丢失是版本问题，手动把tidb的bin拷贝回去覆盖掉升级失败时的4.0.16版本重启就可以了。
集群算是恢复了，但是升级是个老大难问题了
之前从3.0.19升级过很多次4.0版本，数据量有大有小，有比这个更大的，从未发现这个load region的问题，感觉是个例，非普遍现象。

[realcp1018]

目前还有8、9个3.0的老集群跑着，有的是太大不好升，有的是没人关注，近期就把升级计划起来。

[realcp1018]

Update:
更新对时服务chronyd的time server为有效值后正常。最初时因为肉眼观察时间是同步的所以未修改时间同步服务。
另：
升级高版本时遇到DDL job queue异常的问题，https://github.com/pingcap/tidb/issues/41099 等待一并处理。

[会飞的土拨鼠]

【 TiDB 版本】3.0.19 ，可以升级到v5.0 或者v6.0,大家用的版本差不多，可以复现一些问题