目前是整个集群的机器想换到另一套机器，机器配置完全一样。只需要平移。目前考虑2种方案，一种备份数据到新集群还原。一种通过先扩容，再缩容的模式切换到新机器。第二种方案的好处是对服务影响更小，迁移更平滑。想问下第二种方式迁移有人搞过吗，风险高吗。
数据量小的话，可以接收短时间停机的话，最好是冷备份物理备份后还原
建议第一种，第二种估计会有各种问题
如果是在同一套机房，几乎无网络延迟的话没有太大问题，但上层代理层要配对
理论上第二种方法可以，但可能在生产实现起来，风险更大吧
对，目前就是考虑第二种方案不可知风险太高，想看下是否有人处理过，如果风险小可以考虑
感觉还是用cdc同步到新装的库，后面切换下
考虑新老机器之间的网络延迟。
主备没考虑？
如果是同个 IDC ，只是为了更换硬件设备，第二种方案更好啊，TiDB 扩容缩容操作很成熟的，就是周期会长一点，过程中注意控制一下数据迁移速率避免影响业务正常使用。
备份还原吧，刚搞完
扩缩容需要调下tikv的参数，否则region平迁速度很慢 
很不错的想法啊 可以尝试下 记得发心得啊
看数据量吧，第二种方式用过几次目前没遇到过上面提到的“各种问题”
看到你这个问题，我也想问下扩容相关的，现有群集服务器是x86芯片的，是否可以使用国产ARM架构芯片的服务器扩容节点。
建议第一种方案风险比较低
应该没有影响
如果时间要求不高的话，第二个也可以啊，就是region迁移要点时间，如果你通过tiproxy或者haproxy方式访问数据库的话，甚至你的业务都不是很需要停机，可以先扩容tikv，扩容完之后可以观察一段region均衡了，不影响业务再慢慢缩容原来的tikv，这些业务基本都没感知的，pd也是一样，就是切leader时可能稍微有点影响。最后扩容tidb-server时，扩容完，可以在haproxy上（tiproxy自动负载）增加上新节点的负载，后面扩容直接把老的节点负载下掉就可以缩容了。