【 TiDB 使用环境】生产环境
【 TiDB 版本】6.5
【遇到的问题：问题现象及影响】
为了节约服务器成本，计划做服务器迁移。目前集群包含3个PD、7个tidb、22个kv和2个flash。除了kv是两个节点对应一个主机之外，其余都是一个节点对应一个主机。
用的是HA做负载均衡，同步链路上游有两个kafka，下游有一个mysql和一个oracle
分别用ticdc和drainer t2o做同步
tiup和cdc、drainer t2o、HA在同一个主机上。
整体迁移是每次迁移一两个节点观察比较好，还是集中时间一次操作比较好？
请教类似的经验总结出来的成体系的方法论 或者帮忙指出需要关注的点
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
这个冷门需求好冷
没有人回答这个问题，我就简单理一下自己的思路：
逐个替换风险小一些
1、主体思想是先把每个构件的节点分批次做替换，每次替换一小部分,并同步修改HA和相关的配置文件中的地址
2、全部替换完后，替换HA
3、替换
准备工作：
1、梳理所有服务器地址（混合云部署需要区分云上和云下主机），区分哪些是需要做替换的
2、绘制同步链路图，并标注地址（如果需要替换，则要标注是否替换和替换的新地址以及依赖顺序关系）
你可以参考一下这个。
该怎么迁移，和两个地点之间的延迟多高有关系。
如果延迟很高，那么在线迁移就很难不影响业务，也是很难做的。肯定是需要停机时间的。
替换机器时，考虑新老机器之间网络延迟情况
感觉还是一部分一部分迁移比较稳，但可能涉及停机时间
其实主要就是2种选择：
1.搭建新集群，通过cdc同步，待同步无延迟，选择停机时间，直接切换
2.原集群通过扩容方式将新机器纳入，然后慢慢将原机器缩容。
1的优点是可以很方便的回退
2的优点不需要停机时间
1的缺点是，需要进行完整的测试，否则很容易切换过去，业务不正常回退
2的缺点是，老机器和新机器之间的网络要求高，在逐渐扩容缩容的时候观察业务是否收到影响。
如果你的节点不多的话，其实我建议用2，但是你这么多节点，数据量也不小，扩容缩容均衡数据花费的时间太长了，不如方案1.
建议采用分批次迁移的策略，每次迁移一两个节点并进行观察。这样可以减少风险，一旦发现问题可以及时调整策略。集中时间一次性迁移可能会带来较大风险，如果出现问题可能会影响整个服务的可用性
综合数据库的数据量和能接受的停机时间来决定吧。个人觉得如果数据量一般，能够接受一到二天的停机时间的话，不如一次性迁移，可以在测试环境演练一下
通过 扩容 缩容方式 可能会风险小一点。不过就像楼上说的 网络带宽问题。如果在同一个云里面，那就没问题。如果是跨云了。那就要考虑专线专用带宽。只要保证网络通畅。这个问题不太大。
我们一般都是通过扩容缩容的方式来进行迁移的，虽然慢点，但是可靠……
我觉得你这个难点在网络这块,其他的怎么迁移论坛专栏都有,自己搜下迁移都可以找到一堆
太给力了，能避免很多坑
也是准备用扩缩容的方式去做，每次扩展几个节点，运行一段时间后观察，然后缩容掉老节点。大致也是走这个思想，就是担心没有完整的方法论，造成数据库侧长时间不可用。
有没有具体的操作流程，需要做哪些步骤，在什么顺序去做的这种
目前能接受的停机时间是7个小时，顶破天能争取到9个小时。停机一两天是不可能被接受的
是的，有很大风险停机时间内操作不完
这个需要去做考虑，采用的私有云网络延时很难掰扯清楚，曾经出现过对方监控中显示网络情况很好，但在tidb的grafana中监测到的结果是有很长时间的延时。掰扯了很长时间，也没有得到非常明确的定论。
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。