tidb扩容之tiup报错

简介：tiup 在管理tidb集群时，经常会出现授权问题的报错。归根到底是ssh key的问题。

在使用tiup扩容一个tidb集群时，执行命令：

tiup cluster scale-out tidb-cluster-gap-task-archive scale-out.yaml

报错如下：

Error: init config failed: 10.71.51.68:9093: transfer from /home/tidb/.tiup/storage/cluster/clusters/tidb-cluster-gap-task-archive/config-cache/alertmanager-10.71.51.68-9093.service to /tmp/alertmanager_e90bf39a-e938-4267-b937-2c8cb2fed139.service failed: failed to scp /home/tidb/.tiup/storage/cluster/clusters/tidb-cluster-gap-task-archive/config-cache/alertmanager-10.71.51.68-9093.service to tidb@10.71.51.68:/tmp/alertmanager_e90bf39a-e938-4267-b937-2c8cb2fed139.service: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

通过分析报错，发现是ssh key有问题。

为啥会出现这种问题呢？

原来是.tiup的中控节点重新部署过，我们要知道在部署tidb时，tiup是要先copy 服务器上的公钥和私钥到这个目录下：

/home/tidb/.tiup/storage/cluster/clusters/tidb-cluster-gap-task-archive/ssh

然后再通过这个目录下的公钥和私钥，来访问远端的各个节点，在部署节点的同时，把公钥写入authorized_keys里面。

这个时候如果在中控节点更换公钥和私钥也不影响整个集群的正常控制；但是不能把集群节点authorized_keys里的公钥清理掉，因为这个是要被tidb掉中控机tiup来访问控制的。

那紧接着再提出一个问题：

在使用tiup部署tidb节点时，使用tidb用户和root用户一样的吗？

其实是一样的，都是tiup在对应目录

～.tiup/storage/cluster/clusters/tidb-cluster-gap-task-archive/ssh 生成对应的公钥和私钥；

然后再利用生成的公钥和私钥来ssh免密登陆到各个节点上，使用tidb用户(假设配置文件里是tidb用户)来部署节点；

所以不管是使用tidb用户部署，还是用root 用户部署，都是最后会是以tidb用户来登陆到各个tidb节点来实现部署。

总结：使用tiup部署tidb节点时，使用tidb用户和root用户部署效果是一样的，都是会先copy 公钥和私钥到目录～.tiup/storage/cluster/clusters/集群/ssh下面，然后使用配置文件里的配置用户tidb去登陆到目标节点，最后部署节点。