zhihui
(智慧)
1
【 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) 截图此页面
【附件:截图/日志/监控】
zhihui
(智慧)
3
没有人回答这个问题,我就简单理一下自己的思路:
逐个替换风险小一些
1、主体思想是先把每个构件的节点分批次做替换,每次替换一小部分,并同步修改HA和相关的配置文件中的地址
2、全部替换完后,替换HA
3、替换
准备工作:
1、梳理所有服务器地址(混合云部署需要区分云上和云下主机),区分哪些是需要做替换的
2、绘制同步链路图,并标注地址(如果需要替换,则要标注是否替换和替换的新地址以及依赖顺序关系)
有猫万事足
4
你可以参考一下这个。
该怎么迁移,和两个地点之间的延迟多高有关系。
如果延迟很高,那么在线迁移就很难不影响业务,也是很难做的。肯定是需要停机时间的。
1 个赞
感觉还是一部分一部分迁移比较稳,但可能涉及停机时间
其实主要就是2种选择:
1.搭建新集群,通过cdc同步,待同步无延迟,选择停机时间,直接切换
2.原集群通过扩容方式将新机器纳入,然后慢慢将原机器缩容。
1的优点是可以很方便的回退
2的优点不需要停机时间
1的缺点是,需要进行完整的测试,否则很容易切换过去,业务不正常回退
2的缺点是,老机器和新机器之间的网络要求高,在逐渐扩容缩容的时候观察业务是否收到影响。
如果你的节点不多的话,其实我建议用2,但是你这么多节点,数据量也不小,扩容缩容均衡数据花费的时间太长了,不如方案1.
1 个赞
kevinsna
(Ti D Ber P O Zcnp Ja)
8
建议采用分批次迁移的策略,每次迁移一两个节点并进行观察。这样可以减少风险,一旦发现问题可以及时调整策略。集中时间一次性迁移可能会带来较大风险,如果出现问题可能会影响整个服务的可用性
综合数据库的数据量和能接受的停机时间来决定吧。个人觉得如果数据量一般,能够接受一到二天的停机时间的话,不如一次性迁移,可以在测试环境演练一下
舞动梦灵
(Ti D Ber Nckmz Hmh)
10
通过 扩容 缩容方式 可能会风险小一点。不过就像楼上说的 网络带宽问题。如果在同一个云里面,那就没问题。如果是跨云了。那就要考虑专线专用带宽。只要保证网络通畅。这个问题不太大。
呢莫不爱吃鱼
11
我们一般都是通过扩容缩容的方式来进行迁移的,虽然慢点,但是可靠……
templey
(templey)
12
我觉得你这个难点在网络这块,其他的怎么迁移论坛专栏都有,自己搜下迁移都可以找到一堆
zhihui
(智慧)
14
也是准备用扩缩容的方式去做,每次扩展几个节点,运行一段时间后观察,然后缩容掉老节点。大致也是走这个思想,就是担心没有完整的方法论,造成数据库侧长时间不可用。
zhihui
(智慧)
15
有没有具体的操作流程,需要做哪些步骤,在什么顺序去做的这种
zhihui
(智慧)
16
目前能接受的停机时间是7个小时,顶破天能争取到9个小时。停机一两天是不可能被接受的
zhihui
(智慧)
18
这个需要去做考虑,采用的私有云网络延时很难掰扯清楚,曾经出现过对方监控中显示网络情况很好,但在tidb的grafana中监测到的结果是有很长时间的延时。掰扯了很长时间,也没有得到非常明确的定论。