集群容灾cid:link_3备份恢复工具cid:link_4物理细粒度备份恢复基本流程cid:link_5物理细粒度备份恢复使用实践cid:link_6业界常用的容灾方案cid:link_7GaussDB(DWS)的容灾是如何实现的cid:link_8log目录结构cid:link_0定位步骤cid:link_9细粒度容灾cid:link_1容灾前准备cid:link_10容灾配置文件backupRestore.inicid:link_11主备集群倒换配置文件sw_backupRestore.inicid:link_2容灾配置文件backupRestore.inicid:link_12show-progress命令cid:link_13熔断策略https://bbs.huaweicloud.com/forum/thread-02126199798402272061-1-1.html

熔断配置推荐 空闲连接熔断 设置session_timeout为10min stream数量熔断 设置max_streams_per_query为100 执行时长熔断1) 已配置工作负载队列时，在各个工作负载队列配置执行时长，根据业务类型设置阈值。例如，实时查询业务配置600s，跑批分析类业务配置24h； 2) 未配置工作负载队列时，设置statement_timeout参数，根据业务类型设置阈值。例如，实时查询业务配置600s，跑批分析类业务配置24h。 内存熔断 1) 已配置工作负载队列时，管理员用户通过sql语句配置工作负载队列异常规则： ALTER RESOURCE POOL resource_pool_b1 EXCEPT RULE WITH(mem_limit='300MB'); 推荐值：工作负载队列总内存/工作负载队列最小并发。例如，资源池分配总内存为20GB，业务可容忍最小并发为4，则配置阈值为5GB。 工作负载队列总内存=max_process_memory * 工作负载队列内存百分比。 2) 未配置工作负载队列时，设置query_max_mem参数。 推荐值：max_process_memory / 最小并发。 单语句占用空间熔断 设置sql_use_spacelimit参数。 推荐值：空间总大小 * 10% / DN数量。 DN数量可通过select count(*) from pgxc_node where node_namelike '%DN%';进行获取。 单线程下盘空间熔断 设置temp_file_limit参数。 推荐值：空间总大小 * 5% / DN数量。 DN数量可通过select count(*) from pgxc_node where node_namelike '%DN%';进行获取。

show-progress命令显示的主要字段释义如下： priorKey：该备份集是基于这个backup key生成的。 actionType：备份集当前的操作类型。 取值包括如下： Backup，表示备份阶段。 Restore，表示恢复阶段。 progress：备份或恢复操作的进度。 currentStep：备份或恢复正在执行的步骤。 unrestoreKeys：待恢复的key列表。 failedStep：备份或恢复失败的步骤，初始值默认为INIT。 errorMsg：备份或恢复失败的错误信息，如果成功，该字段则显示成功的信息。 errorCode：备份或恢复的错误码，该字段为预留字段，暂未使用。 actionStartTime：当前操作的开始时间。 actionEndTime：当前操作的结束时间。 updateTime：当前操作进度的刷新时间。 backupState：当前备份状态（backuping/stopped/waiting/abnormal）。 restoreState： 当前恢复状态（restoring/stopped/waiting/abnormal）。 backupSuccessTime：上次成功备份结束的时间。 restoreSuccessTime：上次成功恢复结束的时间。 latestBarrierTime：上次主备集群一致点时间。 recovery point objective：rpo时间（当前主集群时间到最后一个恢复成功的备份集备份开始时间）。 failover recovery point time：failover未同步时间点。

standby-cluster-id=22222222-2222-2222-2222-222222222222 # Processes tables for which fine-grained disaster recovery is no longer performed # Value should be 'none', 'log-desync-table', 'drop-desync-table' desync-table-operation=drop-desync-table # Number of CPU cores that can be used by each DR process. Range is (1~1024). cpu-cores=8 # The max number of rch files that can be reserved on master cluster before sent to standby cluster. 0 means no limit. local-reserve-file-count=160# Media destination where the backup must be stored primary-media-destination=/DWS/data2/finedisaster/mediadata # Metadata destination where the metadata must be stored 

primary-metadata-destination=/DWS/data2/finedisaster/metadata # The master-port in which the backup must be executed backup-port=XXXX # Logging level for the log contents of backup:FATAL,ERROR,INFO,DEBUG primary-cluster-logging-level=INFO # Time interval between each restore, uint: min restore-interval=2 # One of the restore hosts restore-host-ip=XXX.XXX.XXX.XX # Media destination where the backup contents must be stored in the standby cluster restore-media-destination=/DWS/data2/finedisaster/mediadata # Metadata destination where the backup contents must be stored in the standby cluster restore-metadata-destination=/DWS/data2/finedisaster/metadata # The master-port in which the restore must be executed restore-port=XXXX 

细粒度容灾的容灾备份过程支持与物理细粒度备份业务并行执行。可通过以下措施隔离： 1. 两个备份任务指定不同的metadata目录和media目录，实现备份数据隔离。容灾备份目录通过容灾配置文件(backupRestore.ini和sw_backupRestore.ini)中的参数primary-media-destination和primary-metadata-destination指定。 2. 细粒度容灾的容灾备份端口与物理细粒度备份的master-port指定为不同的值，实现备份进程端口的隔离。容灾的备份端口通过容灾配置文件(backupRestore.ini和sw_backupRestore.ini)中的参数backup-port指定。容灾配置文件backupRestore.ini 以下是backupRestore.ini文件示例，可根据具体业务场景修改配置参数值。 # Configuration file for SyncDataToStby tool# The backup life cycle life-cycle=10m # The table that records backups info backuprestoreinfo-file=backuprestoreinfo.csv # The cluster user name for cluster username=Ruby # The primary cluster env set primary-env= # The standby cluster env set standby-env= # Time interval between each full backup, uint: min full-backup-exec-time-interval=N/A # Time interval between each backup backup-exec-time-interval=2 # One of the backup hosts primary-host-ip=XXX.XXX.XXX.XX # The media type that restore backup files, DISK media-type=disk # The number of process that should be used. Range is (1~32) parrallel-process=4 # The compression level that should be used for backup. Range(0~9) compression-level=1 compression-type=2 # Media destination where the backup must be stored primary-media-destination=/DWS/data2/finedisaster/mediadata # Metadata destination where the metadata must be stored 

前提条件 确保ssh服务打开。 确保ssh端口不会被防火墙关闭。 确保所有机器节点间网络畅通。 配置互信 1. 依次登录主备集群各节点沙箱外，执行步骤2-4。 2. 将主集群和备集群所有节点ip和hostname添加到/home/Ruby/.ssh/authorized_keys和/var/chroot/home/Ruby/.ssh/authorized_keys的from列表中。 3. 将主集群和备集群所有节点ip和hostname的映射添加到/etc/hosts和/var/chroot/etc/hosts文件中。 4. 遍历主集群和备集群所有节点ip和hostname，执行以下命令。校验互信 从主集群任一节点能免密ssh到备集群任一节点且从备集群任一节点能免密ssh到主集群任一节点，即代表互信已配置成功。 配置容灾配置文件 1. Ruby用户分别登录主备集群主节点沙箱内。 2. 创建容灾目录，假设目录为/DWS/data2/finedisaster 。 mkdir -p /DWS/data2/finedisaster 3. 在/DWS/data2/finedisaster目录下，创建容灾配置文件backupRestore.ini和主备集群倒换配置文件sw_backupRestore.ini。

当前数仓承载的客户业务越来越多，从而导致客户对于数仓的可靠性要求不断增加。尤其在金融领域，容灾备份机制是信息系统必须提供的能力之一。本文介绍了在云上环境的双集群(不跨Region不跨VPC)后台手动部署并使用细粒度容灾的主要步骤，使得用户能快速方便得搭建起细粒度容灾。对于MPPDB集群的容灾而言，目前业界的常见方案要么是部署两套规格配置同等的集群，要么通过逻辑双加载方式去实现，这两个方案缺点比较明显，存在架构复杂、建设成本高等问题，不仅使得灾备部署难度增大，还导致资源浪费。在此背景下，GaussDB(DWS)基于列存表实现细粒度容灾能力，既满足核心分析型业务在极端场景的业务连续性要求，同时也能大幅降低容灾方案的建设成本，而且容灾架构轻量化，容灾系统易运维、易操作、易演练，从而帮助用户迅捷、经济、按需构建核心业务的容灾系统。 相比于传统的容灾方案，细粒度容灾有以下优势： 主集群和备集群双活（Active-Active）（备集群除灾备表只读外，其余表可读写） 主备集群只需满足DN整数倍关系，降低备集群建设资源，方便灵活部署 利用列存表的数据和元数据分离的特点，通过元数据逻辑同步 + 数据物理同步的方式，同步增量，结合UDF的增量抽取/回放接口，保障表级数据一致性 粒度可控，支持表级、schema级、库级容灾 支持表DDL，部分DCL元数据同步，达到切换可用

1. 确定问题在备份侧还是恢复侧，查找双集群主结点上Sync日志，确定出错的模块。 2. 确定出错的层次，由于双集群执行过程是一个上下层调用及时序关系的方式，具体顺序参考： crontab -> SyncDataToStby.py -> GaussRoach.py -> gs_roach 3. 在各个模块都有较详细的日志描述过程，具体问题具体分析，大体有如下几个方面： 配置出错，用户、环境变量文文件 备份集群路径权限问题 由于集群状态非Normal导致备份失败 结点故障及备份集损坏导致恢复失败 4. 后续文章会按模块及错误类型来详细描述问题定位步骤。GaussDB(DWS)的双集群容灾功能是一个独立的复杂的分布式系统，涉及到三层工具的使用，因此在问题定位时会造成一些困惑。定位的方法需要先去理解架构、运行机制，然后根据时序关系去对应结点分析日志。后续会从各个模块的角度介绍一些典型的问题及修复方法。

双集群的日志也是存放到$GAUSSLOG这个目录，并且有自己独立的目录 roach, 由这个目录同样是备份/恢复的对应的log路径。我们按调用关系从上到下的角度来介绍 1. frame目录 存放SyncDataToStby.py生成的log，涉及到双集群调度，备份集清理，状态显示，配置文件及命令行参数解析的功能。 2. controller目录 存放GaussRoach.py生成的log，涉及到备份、恢复准备工作一些操作，备份、恢复参数解析，备份集群的处理，错误处理等。controller目录下以disaster开头命令的文件是容灾的log。 3. agent目录 存放gs_roach工具生成的log，涉及到gs_roach连接gaussdb/gtm/cm发起备份/恢复，生成备份集/恢复备份集等操作。agent目录下以disaster开头命令的文件是容灾的log。 gs_roach工具功能：在备份侧完成将cn/dn/gtm/cm的数据文件按顺序打包成备份文件的功能，并生成备份集元信息文件; 恢复侧根据元信息文件将备份集文件解压到对应cn/dn/gtm/cm的数据目录中。

GaussDB(DWS)的容灾方案是一个双集群同步的架构，即两套独立集群定期同步数据以达到容灾的目的。目前数据同步的方式是通过roach(GaussDB(DWS)备份、恢复工具)定期做增量备份和恢复同步。双集群框架是一个复杂的分布式系统，在出现问题时，如何快速准确的定位问题及恢复服务是一个非常紧迫的问题，这个问题在云上会更突出。本文通过介绍双集群的架构、log结构、分析步骤来介绍双集群容灾的问题分析方法。 备份侧调用关系：SyncDataToStby.py -> GaussRoach.py -> gs_roach 恢复侧调用关系：SyncDataToStby.py -> GaussRoach.py -> gs_roachSyncDataToStby.py是整个双集群的调用起始，控制着双集群的正常运行，正常情况下是常驻内存的进程，如果异常退出后，后台会有crontab的来重新拉起双集群脚本: crontab -> SyncDataToStby.py -> GaussRoach.py -> gs_roach系统的各种log是我们了解运行机制，了解问题现场的有力工具，同样双集群的问题分析也依赖于log的分析，首先认识一下双集群对应的日志。

从GaussDB(DWS)的角度去分析业界目前几种通用的容灾方案： 日志同步技术： 1. 列存数据不记日志无法通过日志来同步。 2. 支持列存xlog后会导致导入性能劣化，xlog数据量大，同时会影响日志同步效率。 备份增量同步技术： 1. 无法达到RPO = 0 2. 备集群只能读，无法支持写操作 逻辑数据同步技术： 1. 列存数据需要支持逻辑解码，需要从列存XLog的方向进行演进 2. 分布式事务，DDL等处理难度较大 备份/恢复 1. 不能马上提供服务，RTO时间较长 2. 需要较大空间保存备份集 应用层双写 1. 需要业务配合，对于业务侵入较多，不具有通用性，无法规模商用。GaussDB(DWS)当前在备份增量同步和备份/恢复两个方向进行演进，他们都是基于备份/恢复工具RoachGaussDB(DWS)需要解决四类问题： (1) 快速的备份恢复：高性能备份、恢复操作保证在较短的时间内将数据迁移到另一个集群，对于RPO/RTO要求不大的系统来说实现和使用非常简单。 (2) 备份恢复在集群可用的情况下即可进行，不受单点故障的影响：备份恢复在集群可用的情况下就可以进行，集群只需要保证有可用副本就可以持续的进行备份，并且可以正常恢复。 (3) 备份集的可靠性：备份集需要存储在可靠的存储上，类似OBS/NBU，由于磁盘故障率相对比较高，类似备份集保存在磁盘上也是一种可选的方案。 (4) 容灾支持程度：支持跨AZ级的容灾还是跨Region级的容灾，是否具有全场景下的容灾能力。

细粒度备份和恢复以更小的粒度对数据文件进行了备份恢复操作。考虑到备份数据的完整性以及备份恢复的性能，细粒度备份过程增加了ddl导出、Map文件生成等关键步骤，其中从数据目录下的物理文件信息到Map信息、再从Map信息到备份的rch文件对应的fine_file_list信息，形成了对备份数据文件连续的记录链条。恢复过程中如果出现缺少数据的情况，可以通过对备份过程中以上所说信息的互相对比快速定位到出现问题的环节，因此，掌握以上信息十分关键，可以帮助我们更好地使用细粒度备份恢复功能。数据仓库系统的可靠性和容灾能力变得越来越重要。与过去不同，现在的数据仓库系统不仅要求在正常情况下提供高性能的服务，还需要在极端情况下迅速恢复，以满足实时性和可用性的需求。因此，拥有可靠的容灾能力已经成为了一个衡量云时代数仓产品成熟度和可用性的重要指标。

由于物理细粒度备份采用了在线恢复的方式，创建了一张新表，那么就需要知道原表的一个表定义，那么在备份的时候就需要将表的定义备份上，这个任务是通过调用GaussDB(DWS) gs_dump工具完成。确定了表定义就要拷贝表对应的相关文件，比如列存表的cudesc表、存在可变长字段的toast表等，只有把辅助表的信息也记录下来，才能保证恢复之后这张表是可用的，物理细粒度备份采用Map文件对表关系进行组织，对表所有的关联表及文件进行统一收集记录，备份和恢复时根据map文件去做表文件的备份和恢复。最后就是物理文件的拷贝，Roach对物理文件的拷贝是通过压缩的方式，然后保存在一个rch文件中，并生成fine_file_list文件，记录每个rch文件压缩了哪些物理文件。备份时备份了表定义、表相关文件、表物理文件三个信息之后，我们便可以进行细粒度单表的恢复。 物理细粒度恢复主要是把一张表或多张表恢复到目标集群中，并保证恢复后的表能够正常提供服务。物理细粒度恢复同样采用的是在线恢复的方式，恢复方法的核心思想是在当前的集群中创建出与原表定义完全相同的一张目标表，再把原表和目标表相关的物理文件进行替换。由于替换之后的物理文件保存了旧的事务信息，因此完成数据恢复后需要对目标表进行数据清洗，至此，所有的恢复工作完成。

为了应对故障场景，防止数据丢失，GaussDB(DWS)提供了两道防线，以保障数仓安全，分别是：高可靠技术和备份恢复技术。高可靠技术是第一道防线，备份恢复技术是最后一道防线。 GaussDB(DWS)的备份恢复工具—Roach，提供了备份、恢复、容灾功能。备份恢复部分包括集群级备份、集群级恢复、物理细粒度备份、物理细粒度恢复、逻辑备份和恢复；容灾部分包括双集群容灾、双集群迁移、细粒度容灾。假设我们误删了一张表，想通过备份将这张表恢复出来，如果我们采用集群级恢复的方式，那么就需要对整个集群的数据进行恢复，这显然不是我们想要的。而如果采用细粒度恢复的方式，我们就可以精确的只将这张表恢复出来。类似这样的场景有很多，实际使用中集群级的故障并非是一个高概率的事情，我们细粒度恢复一张表或一个schema才是更加实际的需求。 物理细粒度备份恢复优势： 节省空间：相比于集群级备份海量的数据备份恢复，物理细粒度备份针对重点文件进行备份，省去了无关数据的备份，节约大量的空间； 节约时间：走物理文件拷贝的流程，相对于逻辑备份更加简单高效； 精准恢复：恢复想要恢复的数据，无需对整个集群数据进行恢复。