更多精彩内容,请登录:ke.sandata.com.cn
一、目的
当前现有服务器状态为同机房两套 Greenplum 集群,节点数为 2 + 4。为满足未来灾备中心建设,需要构架高可用架构方案,以满足未来在生产系统集群出现不可恢复状态下,备用集群可以完全接管生产系统集群,以实现高可用架构。
二、方案
目前方案分为以下两种,一种为数据实时同步高可用方案,一种为允许数据同步有一定的延迟状态。
2.1 数据实时同步高可用架构(本文省略)
架构图如下(不做说明)
当主机中心由于不可抗拒因素或者硬件及认为因素不可用,备机完全接管主机。
2.2 具有延迟性灾备方案
延迟性灾备方案,其目的主要为可以允许部分数据丢失或者损坏,但不允许集群不可用。当生产系统发生故障或者由于不可逆因素(如自然灾害)导致无法对外提供业务时,需要备用系统完全接替生产系统,但对于生产系统上最近同步或者加载的部分数据可以保证在短时间内完成数据的重新加载,因此需要构架一套灾备系统来保证未来服务在一定程度上的高可用性。其架构示意图如下:
此方案有一定的局限性,即多长时间进行同步,同步对生产系统性能影响大小,可靠性测试等,需要进一步验证。
三、方案实现
3.1 全量源表在线同步
通过gpcopy 实现全量原表在线同步复制,如下:
同步源表后结果在备机如下:
同步数据:
同步源表数据后结果在备机如下:
该方式无法实现增量数据同步。
同时,需要注意的是,如果使用该方式进行数据同步,对于源端表数据应该通过pg_dump 的方式进行导出,然后在备用节点服务器进行恢复。
3.2 使用pg_dump和gpcopy进行数据初始化
3.2.1 源端相关结构信息
导出数据库结构
3.2.2 被用集群上恢复相关结构
在备用集群上恢复导出的数据库结构和表结构
为了能够使数据同步更快,建议删除索引并在同步完数据后进行索引重建。
使用 gpcopy 同步数据
使用 gpcopy 同步数据该13G数据大约需要3分14秒,数据传输速率视网络带宽因素影响(该测试环境网络带宽为1000Mbps/s)。
3.2.3 备用主机验证
3.2.4 使用pg_dump和psql恢复数据
源端数据导出
耗时44秒
备用主机数据导入
由于磁盘使用SSD,写入和读取性能测试为2G/s以上,而网络带宽为10GE带宽,为了提高数据写入性能,建议将数据文件拷贝到备用节点,在备用节点使用 psql 恢复数据。
可以看到,即使将数据文件直接拷贝在备用主机上使用 psql 进行恢复,需要4分49秒,实际恢复速度视磁盘性能而定。
以上两种方式都可以进行不同集群之间的数据初始化,但是无法实现未来数据的增量同步。
3.2.5 使用 gptransfer进行数据同步
备用主机查看数据信息
通过gptransfer 实现的数据传输,稳定,耗时整体比gpcopy多,但是多了数据校验的功能。同时,gptransfer 如果在目标端(备用主机)不存在数据库,可以实现函数,资源队列等的同步迁移。
四、结语
对于 Greenplum 数据想要实现数据库灾备架构建设,最好的方案就是通过第一种方案,即使用双 ETL 实现数据双写。对于第二种方案,可以在根据实际的业务需要进行选择,建议使用 gpcopy 和 gptransfer 两种方案,也可以使用 gp_dump 和 gp_restore及gpcrondump和 gpdbrestore方案构建。
Speak Your Mind