【 TiDB 使用环境】测试
【 TiDB 版本】v6.5.9
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
tidb集群在缩容的时候，是否可以直接使用官方的scale-in直接缩容某个节点，如果不建议，这样做会产生什么问题吗？
看你原来的拓扑结构和要缩容的节点
例如你要缩容pd，原来有3个，缩容一个也不是不可以，但是一般建议最好3个保证能选举。如果你原来有4个以上，那肯定随便缩，只要不要缩主节点就行。
如果你要缩容tidb-server，原来有2个以上，也可以缩容，不过缩容时，连接你缩容节点的进程就会受影响，同时剩下的节点压力会变大，如果只有一个，缩了你也用不了了啊。。。
如果是tikv，3副本情况下，如果你的tikv只有3个，你缩不掉的，因为你3副本没地方放，如果有4个及以上，是可以缩容的，只是时间可能稍微长一点，需要等待这个节点上的region迁移走。
如果是tiflash，2个节点以上，也可以缩，只是你原来剩下的节点压力会变大。
按照官方手册没问题
官方写的为啥不建议呢 
你这问题问的挺有问题的呀，所有人都按照官方的步骤来操作的，你竟然想搞一个不用官方建议的方法。目前知道的有两个方法可以干掉一台服务器
- scale-in缩容
- 直接关闭服务器。让他自己下线。
可以直接缩容某个节点
像这个文档中说的以下点：如果默认600秒时间到了，leader还没有迁移完，然后这边说的是跳过等待直接缩容服务，那这样是不是就会影响业务了？
–transfer-timeout（uint，默认 600）
在缩容 PD 或 TiKV 时，会先将被缩容节点的 leader 迁移到其他节点，迁移过程会需要一定时间，可以通过设置 --transfer-timeout 设置最长等待时间（单位为秒），超时之后会跳过等待直接缩容服务。
如果leader的转移超过了默认的超时时间600秒，看官方文档是说会跳过等待直接缩容，这样会有什么影响吗？另外是否会出现执行了scale-in的操作，但是一直都没有变成Tombstone的状态，这种情况要怎么处理？
我看一些文章是说建议先手动迁移走要缩容的tikv节点的leader，等这个tikv节点完全没有leader之后再缩容，是否大家生产环境都是建议这样操作的？
测试环境验证是可以直接缩容，不过生产环境业务比较繁忙，所以大家在生产环境是否先手动将要缩容的节点的tikv节点上的leader先迁移走，再执行scale-in的？
你去执行scal-in，他不会立马成功的，他会先执行迁移。把leader和region全部迁移走。
你也可以自己手动让这个tikv服务器region和region迁移走，等他为0了在执行scale-in，很快就执行完成，
这只是tikv。如果是tidb和pd服务器，很快就完了
还有就是，你直接关机，不管他，他会自动被踢掉。然后手动执行删除对应的这个服务器
1 个赞
超时之后不会停止迁移region啊，你还是得等上面所有region迁移完成，才会从offline变成Tombstone之后才能回收。
1 个赞
如果可能建议tikv节点上的leader先移到其他节点再scale-in
可以呀，可以直接搞，按照官方手册来做，不会有啥问题的一般