【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】V4.0.0
【遇到的问题：问题现象及影响】已经启动的集群，tidb、tikv、tiflash各组件状态都正常，现在我想停止组件中的某一个节点，然后再重新启动，对于官方给的如下停止启动命令，想咨询下，停止指定节点前，是否需要手动把该节点上的leader切换到其他节点，此外，启动指定节点时，是否会对已经处于启动状态的其他组件和节点有影响？另外图片对应的启动命令操作后会把其他节点停掉，只启动这两个节点还是说已经启动的不影响，会额外启动这两个节点？
1、不用手动切leader
2、单启动一个，通常不会对已经处于启动状态的节点产生影响，都是独立运行的
3、启动指定节点的名称或IP只启动这个节点，不影响其他节点
1 个赞
是否需要手动把该节点上的leader切换到其他节点，
原则上是不需要的，tikv 会自动 transfer leader, pd 会一样
启动指定节点时，是否会对已经处于启动状态的其他组件和节点有影响
tiup cluster start -N a,b 的意思是（在当前集群组件的状态下）启动 a，b，如果 a，b 已经是 UP 状态，该命令不会重新启动 a，b
另外图片对应的启动命令操作后会把其他节点停掉，只启动这两个节点还是说已经启动的不影响，会额外启动这两个节点
tiup 做的就是命令行指定的节点操作，不会“额外”对别的节点操作
1、对于tikv，pd来说，stop建议先手动驱逐leader；tidb，tiflash没有leader的概念。
2、tiup cluster reload会自动驱逐leader，并且更新配置重启。
3、启动是调用systemctl start service-port 命令，所以只要端口对应没问题是不会影响其他组件的。
如果涉及的数据量比较大，tikv stop 时 transfer leader 会比较慢，会拉长整个变更的时长，所以最好还是先进行 evict leader；
参考：
tiup ctl:v6.5.8 pd -u http://ip:2379 -i
» store – 查看 store id
» scheduler add evict-leader-scheduler 2 – 驱逐 store 2 上的 region leader
» scheduler remove evict-leader-scheduler-2 --移除调度器
我一般都直接重启，没考虑那么多，当然业务对延迟敏感还是得多注意
1、在停止生产环境的TiDB集群中的某个节点之前，通常建议手动将该节点上的leader迁移到其他节点，以避免在节点停止后，该节点上的leader无法被选举，影响集群的稳定性。您可以使用pd-ctl 工具来调整leader的权重，使其为0，从而让PD调度器将leader迁移到其他节。
2、使用TiUP工具对TiDB集群中的节点进行启动和停止操作时，此过程不会影响其他节点的正常运行
您好，对于您说的第一个观点:建议手动将节点上leader迁移到其他节点，以免在节点停止后，该节点上的leader无法被选举，想问下是什么原因可能导致无法被选举，无法被选举的影响有哪些？此外，假如tikv有7个节点，我需要先停止3个再重新启动，那么会不会因为剩余节点数为偶数个导致集群有额外的影响？
主要是生产在用，不敢直接停
请问这个您有实操过吗，因为是生产环境，怕出问题
请问如何手动驱逐leader呢，有没有具体的命令，比如tikv驱逐的步骤
好的，谢谢
好的，了解
是的 有实操
业务低峰期操作
不需要，直接重启即可
有问题，就重启
分布式数据库的优势就是可以随意的添加或剔除节点啊，踢节点前提是满足当前数据库的压力，比如TiKV节点在剔除之前要确保剩余节点的剩余空间可以接纳剔除节点的数据，再比如剔除TIDB节点前，需判断IO压力和CPU 内存的压力
嗯，看很多网友回复说需要手动清除节点上的leader，所以想确认下如果不手动清理是否有影响？另外，还有一点想了解的是，比如tikv7个节点，我能否临时停止3个然后过一段时间再重新启动，因为清除3个会导致tikv节点数为4个(偶数)，是否会有其他影响？
不需要手动切leader，tidb是自动挡