今天在线上运维过程中,遇到了一个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的扩容缩容步骤,是否有其他注意事项,例如扩容之后需要更新元信息之类,结果发现如下的内容(之前扩缩容的时候,都没有特别留意):
从上述描述中不难看出来,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、所有运维操作之前,建议先查看对应的官方文档,如果之前详细看了官方文档,这个问题就可以提前避免了。