【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】v5.4.0 2tidb 3pd 3tikv 2ha 数据量不到200G.
【复现路径】由于目前集群io瓶颈的原因，打算将数据迁移到新的环境，新的环境2tidb，3pd，5tikv，均为固态硬盘，现在在考虑怎么进行迁移，是通过扩容缩容的方式还是通过备份还原+ticdc的方式，领导给停业务时间为5秒。
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
不要整体迁移，只要网络互通的情况下，挨个增加节点，删除节点就可以了
就是扩容缩容来迁。
扩缩容不需要停机啊
你领导给你5秒 如果是关键业务建议你跑路
关键业务 肯定需要原厂保驾护航呀。非关键是自己折腾
你领导给你5秒 如果是关键业务建议你跑路
停业务时间为5秒，我估计业务执行停启服务都不止5秒吧？
其实你这种情况，如果新环境和老环境网络允许的情况下，建议是在线扩容，可以先扩容tikv，如果想对业务影响较小的情况下，可以一个节点一个节点慢慢扩容，把balance和store limit相关参数调低一点，然后扩容tidb和pd，扩容完成将ha负载增加新tidb的地址，然后慢慢缩容tikv和tidb，最后缩容老的pd，老pd的leader最后缩容，这个可能会造成业务一定的backoff，不过这种情况应该是最保险的了。。。
1 个赞
5秒，采用扩容缩容的方式吧，0秒，要超额完成领导的预期。
1 个赞
老集群有io瓶颈 扩缩容的时候稍微卡一下就不止5秒了， 做好背锅准备
这样想的话，TiCDC也不行呀，都是IO瓶颈。
1 个赞
之前已经扩容缩容了一个tikv节点。
网络是通的，目前确实是按照这个方案在处理，到时候只需要重启ha就行了，您说的“这个可能会造成业务一定的backoff”，这个怎么理解？
IO没那么不堪，只是希望有更好的IO的。
那就还好，就参考楼上大佬的方案就可以，逐个扩容，然后降低速率，缓慢进行。
1 个赞
tidb的pd虽然是3节点多数派原则，你连哪个都能工作，但是实际上都需要请求leader节点的，所以在pd的leader切换的时间点，实际上你的集群是找不到pd的leader节点的，然后就会back off，这时如果正常情况下，你的其他pd节点已经被推举为leader节点，back off就会将原来对老的pd leader请求转到新的leader节点，然后正常完成业务。但是如果你的region量级比较大，有可能你的pd切换leader的速度没有那么快，可能会导致back off的时候还是没找到新的leader节点，可能就会失败，但是你的数据量不到200G，应该问题不大。
另外pd的其他节点可以直接缩容来自动切换（tidb和tikv都可以，当然tikv还是建议一个一个缓慢操作），但是pd的leader建议先切换，后缩容，因为每个pd节点是有所有pd信息的缓存的，你直接缩容leader节点可能导致各个pd缓存的信息不对导致业务受一定的影响，可以先切换，待新环境上的pd leader节点已经正常对外提供服务了，再把老的pd leader（这时已经切换为普通节点）缩容掉。
至于上面说的io瓶颈，我觉得既然你现在都已经瓶颈了，说明业务还能够承受这样的io限制，你先扩容tikv，在扩容的时间点io可能会受负面影响（所以建议你的将balance和store limit的速度放慢一点，尽量降低扩容对io的压力），但是等你的新tikv慢慢上线之后，你的io瓶颈会受到很大的缓解，毕竟新的tikv都是固态硬盘，他们在分担走一部分io压力后，老的节点压力会变小。
1 个赞
1 个赞
感谢大佬的指导，由于数据量不大，风险小些，但是还是会严格按照最优方案来处理每个节点的扩容和缩容，例如tikv会先扩容一个再缩容一个缓慢进行，PD先扩容，然后再切换leader，再缩容，配置相应的balance和store limit。
还是需要重启ha生效新的IP，重启花了1秒。
严谨，也算超额完成了。
1 个赞
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。