TiDB元信息案例一例
今天在线上运维过程中，遇到了一个TiDB元信息的问题，最终通过查阅官方文档解决，这里记录一下。
01
背景
背景介绍：
线上TiDB版本4.0.5，在查询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地址10.xx.xx.151，不是集群中的IP地址。
利用tiup cluster display cluster_name查询不到这个IP地址。
那为什么TiDB集群会访问这样一个地址？原因是什么呢？
从报错上看，show config命令是要调用pd的api来访问集群中每个组件的配置，这个报错更像是访问pd超时。那么唯一的解释就是它访问的pd IP地址错误，也就是说tidb组件里面记录的pd元信息出错。
经过排查操作历史，发现这个错误的pd IP地址，曾经是集群里面的pd leader，但是经过一系列的pd缩容、扩容操作，现在这个IP已经不在集群中了。
02
排查思路
查询官方文档，查看pd的扩容缩容步骤，是否有其他注意事项，例如扩容之后需要更新元信息之类，结果发现如下的内容（之前扩缩容的时候，都没有特别留意）：
TiKV 中的 PD Client 会缓存 PD 节点的列表。
- 在 v4.0.3 版本之前，TiKV 不会定期自动更新该 PD 节点列表的缓存，只有在 PD leader 发生切换或 TiKV 重启加载最新配置后才会更新。为避免 TiKV 缓存的 PD 节点列表过旧的风险，在扩缩容 PD 完成后，PD 集群中应至少包含一个扩缩容操作前就已经存在的 PD 节点成员。如果不满足该条件，你需要手动执行 PD transfer leader 操作以更新 TiKV 中的 PD 缓存列表。
- 在 v4.0.3 及以后的版本中，增加了定期自动更新 PD 节点的机制，可以降低 TiKV 缓存的 PD 节点列表过旧这一问题出现的概率。但仍应尽量避免在扩容新 PD 后直接一次性缩容所有扩容前就已经存在的 PD 节点。如果需要，请确保在下线所有之前存在的 PD 节点前将 PD 的 leader 切换至新扩容的 PD 节点。
从上述描述中不难看出来，v4.0.3是一个分水岭：
4.0.3之前，PD发生切换或者TiKV重启的时候，才会更新缓存中的PD元信息；
4.0.3之后，定期自定更新PD节点的机制，但是还是应该确保下线所有之前PD之前将PD Leader扩容到新的PD节点。
我们线上的版本是4.0.5，按理说，会自动更新。但是实际上，识别的PD元信息还是错误的。
那怎么办？手工触发一次PD 的Leader选举试试。
03
解决办法
手工触发PD Leader选举的办法如下：
方法一：
利用pd-ctl的交互模式
pd-ctl -i -u http://pd_addr:pd_port
执行：
member leader resign
将member的leader从当前节点迁移走
或者执行：
member leader transfer new_pd_name
将member的leader从当前节点迁移搭到new_pd_name上
方法二：
利用pd-ctl的命令模式(去掉-i)
执行：
pd-ctl -u http://pd_addr:pd_port member leader resign
将member的leader从当前节点迁移走
或者执行：
pd-ctl -u http://pd_addr:pd_port member leader transfer new_pd_name
将member的leader从当前节点迁移搭到new_pd_name上
总结：
1、低版本的TiDB设计上还是有一些不太合理的地方，从4.0开始引入了TiUP这个工具，建议使用TiUP来管理集群，并及时对集群进行升级，享受高版本的红利。
2、所有运维操作之前，建议先查看对应的官方文档，如果之前详细看了官方文档，这个问题就可以提前避免了。
