GaussDB(DWS) 容灾的介绍
1. 前言
- 适用版本:【8.1.3 版本及以上】
在当今的云时代,数据仓库系统的可靠性和容灾能力变得越来越重要。与过去不同,现在的数据仓库系统不仅要求在正常情况下提供高性能的服务,还需要在极端情况下迅速恢复,以满足实时性和可用性的需求。因此,拥有可靠的容灾能力已经成为了一个衡量云时代数仓产品成熟度和可用性的重要指标。
2. 业界常用的容灾方案
从GaussDB(DWS)的角度去分析业界目前几种通用的容灾方案:
- 日志同步技术:
- 列存数据不记日志无法通过日志来同步。
- 支持列存xlog后会导致导入性能劣化,xlog数据量大,同时会影响日志同步效率。
- 备份增量同步技术:
- 无法达到RPO = 0
- 备集群只能读,无法支持写操作
- 逻辑数据同步技术:
- 列存数据需要支持逻辑解码,需要从列存XLog的方向进行演进
- 分布式事务,DDL等处理难度较大
- 备份/恢复
- 不能马上提供服务,RTO时间较长
- 需要较大空间保存备份集
- 应用层双写
- 需要业务配合,对于业务侵入较多,不具有通用性,无法规模商用。
GaussDB(DWS)当前在备份增量同步和备份/恢复两个方向进行演进,他们都是基于备份/恢复工具Roach
3. GaussDB(DWS)的容灾需要解决哪些问题
GaussDB(DWS)需要解决四类问题:
(1) 快速的备份恢复:高性能备份、恢复操作保证在较短的时间内将数据迁移到另一个集群,对于RPO/RTO要求不大的系统来说实现和使用非常简单。
(2) 备份恢复在集群可用的情况下即可进行,不受单点故障的影响:备份恢复在集群可用的情况下就可以进行,集群只需要保证有可用副本就可以持续的进行备份,并且可以正常恢复。
(3) 备份集的可靠性:备份集需要存储在可靠的存储上,类似OBS/NBU,由于磁盘故障率相对比较高,类似备份集保存在磁盘上也是一种可选的方案。
(4) 容灾支持程度:支持跨AZ级的容灾还是跨Region级的容灾,是否具有全场景下的容灾能力。
4. GaussDB(DWS)的容灾是如何实现的
GaussDB(DWS)的容灾方案是一个双集群同步的架构,即两套独立集群定期同步数据以达到容灾的目的。目前数据同步的方式是通过roach(GaussDB(DWS)备份、恢复工具)定期做增量备份和恢复同步。双集群框架是一个复杂的分布式系统,在出现问题时,如何快速准确的定位问题及恢复服务是一个非常紧迫的问题,这个问题在云上会更突出。本文通过介绍双集群的架构、log结构、分析步骤来介绍双集群容灾的问题分析方法。
首先介绍一下双集群的部署方案原理,从部署架构和重要参数两个方面先介绍一下背景知识,便于更好理解问题分析的方法。
4.1 架构简介
4.1.1 逻辑结构示例
下图是一个同构的双集群部署示意图,主备集群都是3c3d, 主集群的主结点部署双集群框架脚本,定期进行备份操作,备集群的主结点定期恢复备份集。基础数据需要进行一全量备份,之后增量备份。
4.1.2 部署架构
下图是接上图的部署架构,涉及双集群同步脚本(SyncDataToStby.py), 备份程序(GaussRoach.py, gs_roach)三个执行程序。
备份侧调用关系:SyncDataToStby.py -> GaussRoach.py -> gs_roach
恢复侧调用关系:SyncDataToStby.py -> GaussRoach.py -> gs_roach
了解调用关系和咱们分析问题有直接的关系。
SyncDataToStby.py是整个双集群的调用起始,控制着双集群的正常运行,正常情况下是常驻内存的进程,如果异常退出后,后台会有crontab的来重新拉起双集群脚本: crontab -> SyncDataToStby.py -> GaussRoach.py -> gs_roach
4.2 主要参数介绍
参数名 | 作用 | 备注 |
---|---|---|
username | 执行双集群脚本的OS用户,设置成GaussDB(DWS)集群相同的OS用户 | |
primary-env | 主集群的环境变量文件 | |
standby-env | 备集群的环境变量文件 | |
full-backup-exec-time-interval | 全量备份的间隔时间,当前默认N/A,只进行一次全量备份,分钟为单位。 | |
backup-exec-time-interval | 备份间隔时间,增量备份的间隔时间,分钟为单位。 | |
primary-host-ip | 主集群主结点的ip | |
compression-level=1 compression-type=2 |
压缩算法 | |
primary-media-destination primary-metadata-destination |
主集群的备份目录 | |
restore-interval | 恢复的时间间隔,分钟为单位 | |
restore-host-ip | 备集群的主结点ip | |
restore-media-destination restore-metadata-destination | 备集群备份目录 |
4.3 问题定位
众所周知,系统的各种log是我们了解运行机制,了解问题现场的有力工具,同样双集群的问题分析也依赖于log的分析,首先认识一下双集群对应的日志:
4.3.1 log目录结构
由上节的逻辑图及部署图,每个二进制对应的log文件如下图所示,对应二进制的信息查找对应的log。
如上图,双集群的日志也是存放到$GAUSSLOG这个目录,并且有自己独立的目录 roach, 由这个目录同样是备份/恢复的对应的log路径。我们按调用关系从上到下的角度来介绍
- frame目录
存放SyncDataToStby.py生成的log,涉及到双集群调度,备份集清理,状态显示,配置文件及命令行参数解析的功能。
- controller目录
存放GaussRoach.py生成的log,涉及到备份、恢复准备工作一些操作,备份、恢复参数解析,备份集群的处理,错误处理等。controller目录下以disaster开头命令的文件是容灾的log。
- agent目录
存放gs_roach工具生成的log,涉及到gs_roach连接gaussdb/gtm/cm发起备份/恢复,生成备份集/恢复备份集等操作。agent目录下以disaster开头命令的文件是容灾的log。
gs_roach工具功能:在备份侧完成将cn/dn/gtm/cm的数据文件按顺序打包成备份文件的功能,并生成备份集元信息文件; 恢复侧根据元信息文件将备份集文件解压到对应cn/dn/gtm/cm的数据目录中。
4.3.2 定位步骤
-
确定问题在备份侧还是恢复侧,查找双集群主结点上Sync日志,确定出错的模块
-
确定出错的层次,由于双集群执行过程是一个上下层调用及时序关系的方式,具体顺序参考:
crontab -> SyncDataToStby.py -> GaussRoach.py -> gs_roach -
在各个模块都有较详细的日志描述过程,具体问题具体分析,大体有如下几个方面
- 配置出错,用户、环境变量文文件
- 备份集群路径权限问题
- 由于集群状态非Normal导致备份失败
- 结点故障及备份集损坏导致恢复失败
-
后续文章会按模块及错误类型来详细描述问题定位步骤
小结
GaussDB(DWS)的双集群容灾功能是一个独立的复杂的分布式系统,涉及到三层工具的使用,因此在问题定位时会造成一些困惑。定位的方法需要先去理解架构、运行机制,然后根据时序关系去对应结点分析日志。后续会从各个模块的角度介绍一些典型的问题及修复方法。
- 点赞
- 收藏
- 关注作者
评论(0)