今天在线上的TiDB的运维过程中,遇到了一个问题:
在使用TiUP工具在某个服务器A上扩容tidb节点的时候,扩容命令提示ssh配置一直报错;报错内容:
但是我们手工在管理机器执行ssh远程登录服务器A,则没有报错;
通常情况下,我们会使用下面的命令来查看一个TiDB集群的配置:
tiup cluster check cluster_name --cluster
在使用这个命令查看TiDB集群配置的时候,发现部分节点的状态是Error,正常应该都是Done。
根据官方文档的提示(如下图)排查了很长时间,问题始终没有解决。
于是在asktug上提了一个问答:
https://asktug.com/t/topic/274430
最终得到了结果:
TiDB依赖的SSH秘钥和管理机的SSH秘钥不一致。
我们分别说说这俩秘钥的概念:
1、TiDB依赖的SSH秘钥。
在我们执行tiup cluster list命令列举tiup管理的集群信息之后,输出结果中其实已经有TiDB依赖的SSH秘钥了:
[root@ ~]# tiup cluster list Starting component `cluster`: /root/.tiup/components/cluster/v1.8.0/tiup-cluster list Name User Version Path PrivateKey ---- ---- ------- ---- ---------- tidb_lock root v5.0.0 /root/.tiup/storage/cluster/clusters/tidb_lock /root/.tiup/storage/cluster/clusters/tidb_lock/ssh/id_rsa
最后一行,最右侧,即为TiDB依赖的SSH秘钥
2、管理机的SSH秘钥
其实也就是我们配置SSH互信的秘钥,通常情况下,都在当前用户目录的~/.ssh/id_rsa和~/.ssh/id_rsa.pub这俩文件。
加入你的用户是root,那么~替换成/root即可。
这俩秘钥在初始化的时候,应该是一样的。但是由于后续在管理机上执行了ssh-keygen命令,重新生成了新的秘钥,覆盖了管理机原来的~/.ssh/id_rsa和~/.ssh/id_rsa.pub文件,导致这二者不一致。最终产生报错。
解决方案:
以TiDB使用的秘钥为准,覆盖用户目录下的~/.ssh/id_rsa和~/.ssh/id_rsa.pub秘钥即可。
这个问题虽然解决了,在这个问题解决的过程中,官方人员给了一个比较详细的TiDB部署时候涉及的账号文档,让我对这个账号又有了进一步的理解:
https://asktug.com/t/topic/95777
里面从以下三个维度对TiDB的账户做了分析:
有兴趣的同学,一定不要错过。