GaussDB(DWS)的容灾应该如何设计
本文接 [数据仓库]双集群系统方案探讨 展开讨论一下GaussDB(DWS)的容灾应该如何设计。
对于方案探讨中涉及到几种形态,从数仓内核的角度去分析一下各个方案的问题:
日志同步技术:
列存数据不记日志无法通过日志来同步
支持列存xlog后会导致导入性能劣化,xlog数据量大,同时会影响日志同步效率
备份增量同步技术:
无法达到 RPO = 0
备集群只能读,无法支持写操作
逻辑数据同步技术:
列存数据需要支持逻辑解码,需要从列存XLog的方向进行演进
分布式事务,DDL等处理难度较大
备份/恢复
不能马上提供服务,RTO时间较长
需要较大空间保存备份集
GaussDB(DWS) 当前在备份增量同步和备份/恢复两个方向进行演进,他们都是基于备份/恢复工具Roach
(详情参见Roach备份恢复GaussDB(DWS))
备份/恢复
备份/恢复的原理图如下,在各个结点将实例备份到相应的介质上,并从介质上恢复到新集群或老集群中。详细的功能不在此处展开描述,大家可以参考(详情参见Roach备份恢复GaussDB(DWS)) 来了解细节。
对于实现容灾要求,需要解决的问题大体分三类:
快速的备份恢复
高性能备份、恢复操作保证在较短的时间内将数据迁移到另一个集群,对于RPO/RTO要求不大的系统来说实现和使用非常简单。
备份恢复在集群可用的情况下即可进行,不受单点故障的影响
备份恢复在集群可用的情况下就可以进行,集群只需要保证有可用副本就可以持续的进行备份,并且可以正常恢复。
备份集的可靠性
备份集需要存储在可靠的存储上,类似 OBS/NBU, 由于磁盘故障率相对比较高,类似备份集保存在磁盘上是非可靠的方案。
双集群备份增量同步技术
当前GaussDB(DWS)使用在备份/恢复的双集群架构来实现容灾,将生产集群的数据使用增量的方式同步到容灾的集群。
在这种架构下需要解决如下问题:
减少RPO
备份恢复无法达到与流式的同步方式的RPO, 做不到RPO=0的程度。
备集群的可用性问题
备集群支持持续读/写
备集群是物理恢复的方式,无法支持写的操作的;但是在恢复过程中是可以支持持续读的,当前在恢复过程中需要停集群后将备份集中文件覆盖。
备集群集群恢复失败可回退到一致性状态
在恢复过程中会出结点故障,备份集损坏等等问题,会造成当前的恢复过程无法执行过去,此时需要回退到恢复前的状态,保证备集群的可用性。
备集群恢复不受单点故障影响
对于备集群来说,也会出现各种单点故障的情况,实例故障,结点故障,CN剔除等情况下,仍然可以把集群恢复成可用的状态。
备集群支持备份
备集群可以支持备份,用于扩展一些其它功能,实现类似多AZ,异地的容灾。
3. 备份集管理
1. 备份集生命周期管理
容灾是实现数据同步的功能,并非一个备份恢复场景,并不需要保存大量备份集以及周期的去做全量备份,因此需要有一个机制实现备份集及时清理,保证占用资源可按。
2. 备份集的可靠性
在容灾过程中,同样考虑备份集的可靠性,防止备份集损坏情况,可以通过可靠的介质来保存备份集,又能保证可靠的读写性能。
3. 持续增量数据同步
保持持续的增量备份,类似升级前后,扩容前后,都要保持增量备份来保证同步的性能。这里隐含着一个显而易见的原因,如果全量备份的话,备份时间长,并且恢复进会将集群清空,此时容灾集群不可用,这个严重影响可用性。可以说避免全量备份是基于Roach的双集群容灾一个重要工作。
4. 双集群切换及Failover
1. 快速切换
双集群的应用场景中,类似滚动升级,故障演练,此时需要切换两个集群,切换时要保证快速将两边数据拉平,尽快提供服务并保证可用性。
2. Failover及之后的加回操作
由于RPO != 0,所以在生产集群无法提供服务时,容灾集群在Failover操作后会提供读写服务,此时会有一部分数据丢失,并在两个集群的数据产生了“分叉”,那么在生产集群恢复后,加回之后中要将“分叉”的数据进行回退,以保证两边数据一致。
5. 异构的支持
此处异构是指逻辑结构DN数量一致,而CN数、结点数可以不相同的情况,众所周知是由于当前方案是物理备份方式,因此如果DN数量发生变化,无法从物理层进行重分布操作。
以上说明的几点都是基于可靠性的角度来分析,还有一个重要的因素是基于数仓的数据量和集群规模,不论备份/恢复方案还是在此基础上的双集群备份增量同步的方案,对于网络带宽,介质的读写性能有较高的要求,因此需要根据集群规模和数据增量来选择合适的组网方式和介质。
- 点赞
- 收藏
- 关注作者
评论(0)