tidb集群在缩容的时候,是否可以直接使用官方的scale-in直接缩容某个节点

【 TiDB 使用环境】测试
【 TiDB 版本】v6.5.9
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】
tidb集群在缩容的时候,是否可以直接使用官方的scale-in直接缩容某个节点,如果不建议,这样做会产生什么问题吗?

https://docs.pingcap.com/zh/tidb/stable/tiup-component-cluster-scale-in文档写的很清楚

看你原来的拓扑结构和要缩容的节点
例如你要缩容pd,原来有3个,缩容一个也不是不可以,但是一般建议最好3个保证能选举。如果你原来有4个以上,那肯定随便缩,只要不要缩主节点就行。
如果你要缩容tidb-server,原来有2个以上,也可以缩容,不过缩容时,连接你缩容节点的进程就会受影响,同时剩下的节点压力会变大,如果只有一个,缩了你也用不了了啊。。。
如果是tikv,3副本情况下,如果你的tikv只有3个,你缩不掉的,因为你3副本没地方放,如果有4个及以上,是可以缩容的,只是时间可能稍微长一点,需要等待这个节点上的region迁移走。
如果是tiflash,2个节点以上,也可以缩,只是你原来剩下的节点压力会变大。

按照官方手册没问题

官方写的为啥不建议呢 :joy_cat:

你这问题问的挺有问题的呀,所有人都按照官方的步骤来操作的,你竟然想搞一个不用官方建议的方法。目前知道的有两个方法可以干掉一台服务器

  1. scale-in缩容
  2. 直接关闭服务器。让他自己下线。

可以直接缩容某个节点

像这个文档中说的以下点:如果默认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

可以呀,可以直接搞,按照官方手册来做,不会有啥问题的一般

这些都是自动完成的,不需要手动来执行;真正的分布式数据库,scalability很强的

字最多,我信了。 :100: