为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】线上环境
【概述】tikv存储的pd原信息不准
【背景】前期对pd节点进行了扩缩容，扩缩容之后发现tikv存储的pd元信息有问题
【现象】登陆tidb组件，执行show config，报错如下：
ERROR 1105 (HY000): Get http://10.xx.xx.151:2381/pd/api/v1/config/cluster-version: dial tcp 10.xx.xx.151:2381: i/o timeout
其中，报错的IP地址为缩容的IP地址。
考虑到tikv更新缓存不及时，已经通过pd-ctl工具，手工执行了pd transfer leader操作，但是问题依旧没有得到解决。
【业务影响】业务暂时无影响
【TiDB 版本】4.0.5
【附件】
TiUP Cluster Display 信息
TiUP Cluster Edit Config 信息
TiDB- Overview 监控
tiup cluster display看下集群状态
我发现过了一段时间之后，show config可以查看到状态了。不确定检测到pd元信息变更，是否需要一点生效时间？
tidb有那种 某个Pd节点出问题了，然后tikv或tidb server还会连这个pd导致报错
节点信息好像正常
不行可以试试把你的tikv节点一个一个重启一下，4个tikv节点一个一个重启应该不会有什么大问题
看报错明显是tidb-server到pd集群的网络超时，需要以下排查：
1）tidb-server到pd集群节点的网络质量如何（是否有丢包）？
2）pd集群的负载如何（IO和CPU方向）？
这个问题是由于老版本 TiDB 使用配置中的数据作为 PD 节点数据，而不是使用 PD 的 member api 的数据，导致通过 SQL 查询到的 PD 节点情况与实际不符。
解决版本：
相关 issue/pr:
这个配置中的数据指的是tikv里的meta信息吧，这个配置信息已经不对了该怎么清除？
information_schema.cluster_info 的信息是存储在 PD 的 etcd 中的哈 
这句不太明白 无论通过SQL还是API不都是查询pd里的数据吗？
这个确认了下。4.0.7 之后的版本 information_schema.cluster_info 的信息是存储在 PD 的 etcd 中的。
在 4.0.7 之前的版本，也就是帖子的这个问题，因为之前不走 API，TiDB 是通过读 tiup 这种部署工具的集群拓扑配置来作为 PD 的 cluster info 返回的，但是如果集群启动以后有过从改配置以外的手段变更过，那不就对不上了嘛，所以不是这个信息存在哪的问题。重启 tidb 节点是为了重新读一下最新的配置文件来更新。
大概也只能解释到这里了。。。陈年 BUG 不好翻原因 
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。
