为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
【概述】V3.0版本，使用ansible安装tidb集群，inventory.ini指定如下参数：
[pd_servers]
10.103.6.34
10.103.6.37
10.103.6.39
Global variables
[all:vars]
deploy_dir = /data/tidb/deploy
正常安装完，使用一段时间后。
添加pump，如下配置：
Binlog Part
[pump_servers]
10.103.6.34 deploy_dir=/data/tidb/pump
10.103.6.37 deploy_dir=/data/tidb/pump
10.103.6.39 deploy_dir=/data/tidb/pump
其中pump_servers服务器上也安装pd服务。
然后执行如下操作：
ansible-playbook deploy.yml -l 10.103.6.34,10.103.6.37,10.103.6.39
ansible-playbook start.yml --tags=pump
ansible-playbook rolling_update.yml --tags=tidb
ansible-playbook rolling_update_monitor.yml --tags=prometheus
使用一段时间后发现pd服务配置也被deploy到/data/tidb/pump目录，但是由于pd服务没有重启，还是写在老的 /data/tidb/deploy目录；
【TiDB 版本】V3.0
现在需要怎么操作，才能恢复现有的集群？
1 个赞
xfworld
(魔幻之翼)
2
Pump 服务干嘛要和 PD 放一起？
对于这个情况，想简单恢复估计也没什么好办法了。
如果数据库可以停止服务，建议先备份数据，备份完毕以后，可以尝试两种办法：
方法 一，轻量级修复：
- ansible 卸掉 pump 服务
- 在重启集群，查阅集群状态、
方法 二 ，重量级修复：
- 方法一 如果无法解决问题，就清理所有相关的服务器
- 重建整个集群，导入数据
以上的苯办法，供你参考！
1 个赞
是否可以添加新的3个PD节点，通过扩缩容的方式替换原有节点？
1 个赞
liubo
(Liubo)
4
出现这个问题的原因是
1、deploy.yml -l 指定 ip 会将所有匹配到的 ip 符合的节点都执行 deploy，所以 pd 也会被重新部署
2、相同 ip 或者别名的节点的变量会互相覆盖，最终只有一个变量生效，所以 pd 的 deploy_dir 被 pump 的 deploy_dir 变量覆盖了。
正确的方式应该是：
1、inventory.ini 中相同 ip 的节点都加上别名，例如:
pump1 ansible_host=10.103.6.34 deploy_dir=/data/tidb/pump
pump2 ansible_host=10.103.6.37 deploy_dir=/data/tidb/pump
2、运维操作也将 -l 指定 ip 改成 -l 指定别名：-l pump1,pump2
上述问题的解决办法就是添加别名来区分相同 ip 的节点，添加别名之后错误部署的 pd 应该不会有任何影响。
1 个赞
问题是现在pump和pd已经大概跑了有一年了，您的意思是我重新deploy一下pd 用别名的方式？
1 个赞
liubo
(Liubo)
6
不用重新 deploy，放着别管他就行，加了别名后面的操作就回归正轨了，没有启动的 pd 也没有影响。不放心的话，可以加上别名之后，对其中一个 pd 操作试一下。
建议所有节点都加上不同别名（可以自己指定别名规范）吧，规避同名节点出问题的风险。
同名节点指：
- 没有加别名情况下，相同 ip 的不同节点
- 加别名之后，别名相同的不同节点
1 个赞
我感觉你可能还没理解，我现在害怕的是：
1、如果pd服务出现问题 我重启启动的时候，数据目录不对是否就启动不了，影响集群。我想在不影响线上的情况下修复这个问题，重新部署pump。
2、想从3.0升级到4.0版本，害怕滚动的时候现有的情况会出问题。
大佬 是否有好的方法步骤，分享一下 谢谢！
1 个赞
liubo
(Liubo)
8
一、好久没搞了，我确实忘了一个点：
1、如果你是用的 systemd 方式，上述的错误部署，会导致 systemd 管理的 pd 目录发生了错误，即指向了错误部署的路径。这个可以自行 vim 修改正确，或者改了别名之后重新 deploy pd。
2、如果使用的 supervise 方式那就没有问题，请往下看。
二、【一】中的搞定之后，你现有的服务不用做任何改动。你的问题实际上就是因为 pump 和 pd 的 ip 相同导致 pd 在 pump 目录重新部署了一套，没问题的根据是（加上别名之后）：
- 改了别名之后，操作就会找到正确的 pd，以后的 ansible 命令就不会对错误部署的 pd 做任何操作
- ansible 的 tag 是根据 inventory 中的组来做操作的，对 pd 组操作 (–tags=pd)，只会对 [pd_servers] 组做变动，加了别名的话，变量不会被覆盖，也就是他只会找到原来正确的 [all:vars] 下面的变量
- pump 操作就更没关系了，对 pump 的操作也只会对 pump 所在节点和目录操作
- 没有启动新的 pd，不会有影响。
- 其他服务因为连 pd 是连得 ip:port，所以错误部署的 pd 没有起来，tidb 和 tikv 等服务没有连到错误的 pd 集群，也不会有问题
你可以测试对 pd 的 follower 节点做一个 stop 操作试试（使用 pd-ctl 或者 curl api 来看哪个是 leader。执行 ansible 就用 --tags=pd -l 别名），两个结果：
1、集群操作恢复正常，能停掉对应的 pd 服务，那集群就没任何问题
2、集群操作还是对错误部署的节点做了操作，那就停不掉服务（因为就没启动）
PS：当然也小概率可能出现操作正确的 pd 但是没有停掉的问题，可以执行时候加上 -vvv 观察具体操作执行的命令，也可以去看系统日志等。（小概率事件，有问题可以按这个来查）。
3 个赞
xfworld
(魔幻之翼)
10
扩缩容，貌似是一个比较简单的办法，可以尝试一下
用新的节点，接管旧的节点，缩容旧的节点，然后在把pump 下线
1 个赞
我尝试了一下 用别名再deploy了一遍pump，然后滚动升级了下pd，发现也是正常的。
具体操作步骤：
修改inventory.ini配置
[pump_servers]
pump1 ansible_host=10.103.6.111 deploy_dir=/data/tidb/pump
pump2 ansible_host=10.103.6.112 deploy_dir=/data/tidb/pump
pump3 ansible_host=10.103.6.113 deploy_dir=/data/tidb/pump
ansible-playbook deploy.yml --tags=pump -l pump1,pump2,pump3
ansible-playbook rolling_update.yml --tags=pump
ansible-playbook rolling_update.yml --tags=tidb
ansible-playbook rolling_update.yml --tags=pd
ansible-playbook rolling_update_monitor.yml --tags=prometheus
3 个赞
system
(system)
关闭
14
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。
