原 GreenPlum之搭建gpdr灾备环境（容灾环境、数据实时同步）

概述

公司很多项目上使用了GreenPlum环境，客户基本都有一个要求，需要增量备份或做异地容灾，这对GP来说挺难的。

1、GP属于分布式数据库，除非是AO表，否则不支持增量备份，所以每次只能做全量备份，好在支持S3备份，可以做异地备份

2、GP不像Oracle有DG做容灾，PG有物理流复制，MySQL更不用说了，主从复制、MGR等技术太多了，SQL Server也有镜像复制、always on等技术，都可以用于容灾环境。

在发现GPDR（Greenplum Disaster Recovery）工具之前，给客户提供的方案都是先搭建2个GP集群，然后通过ETL工具进行增量抽取同步的方案实现容灾，但这种方案是逻辑上的，且需要对表做一定的修改，例如增加时间字段。

近期，惊喜的发现了官方提供了GPDR（Greenplum Disaster Recovery）工具，这不就是我想要的么，于是花了半个月时间研究了一下，感觉这个工具还是非常不错的，这里，麦老师把相关整理好的内容分享给大家，包含大家最期待的实战内容和官网没有的shell脚本，这可能是除了官网外，全网唯一的资料了。

部分中文内容直接翻译自官网！！！

什么是灾难恢复(Disaster Recovery)

数据库灾难是导致数据丢失或服务中断的事件。灾难的原因可能有很多，例如电力故障、硬件故障、人为错误和环境灾难等。这些灾难通常难以预测，而且有些是无法避免的。因此，保护数据成为任何企业应用中的一个至关重要的问题。

Greenplum灾难恢复功能（GPDR，Greenplum Disaster Recovery）旨在--在发生灾难的情况下，实现时间点恢复(PITR )，将整个Greenplum群集恢复到灾难发生前的某个恢复点。Greenplum灾难恢复基于预写日志记录(WAL)归档为Greenplum Database提供灾难恢复功能。它允许您对数据库集群的文件执行完整和增量备份，并根据您创建的还原点从备份中执行时间点恢复(PITR)。

PITR 是使用物理备份和恢复点的组合，将整个主集群恢复到某个特定时间点的能力。

GPDR（Greenplum Disaster Recovery）的架构

GPDR架构由一个主集群、一个存储库和一个恢复集群组成。

• 主集群是生产集群。这是工作负载向其发出请求的群集；这是灾难中受损的群集，是需要备份的群集。
• 存储库是写入物理备份和WAL归档文件的存储，恶意是S3、NFS、Dell Data Domain、Google Cloud Storage或本地文件系统。
• 恢复群集是将备份和WAL归档文件还原到的群集。

在使用 GPDR 时按阶段执行的任务：

• 准备阶段：准备主集群、恢复集群以及存储库，以便进行灾难恢复。
• 数据同步阶段：引导恢复集群，保持恢复集群与主集群同步，监控备份进度，列出备份和恢复点，显示恢复信息，并使备份数据集和恢复点过期。
• 故障切换和故障恢复阶段：将恢复集群故障切换，使其成为临时主生产集群，同时修复原主集群的健康状况，然后通过将恢复集群故障恢复，重新将生产责任交还给原主集群。

只读副本模式

恢复集群可以通过启用只读副本模式来支持只读用户查询。通过持续恢复到更新的恢复点，可以使恢复集群上的数据保持最新，以便进行用户查询。

更多请参考： Read Replica Mode. https://techdocs.broadcom.com/us/en/vmware-tanzu/data-solutions/tanzu-greenplum-disaster-recovery/1-2/gp-disaster-recovery/read_replica.html

Tanzu Greenplum灾难恢复通过启用只读副本模式，使恢复集群能够处理只读用户查询。恢复集群上的数据可以通过持续的恢复操作不断更新，恢复操作与用户查询并行运行。每个用户查询自动使用基于最后成功恢复的事务快照，以确保在执行过程中的数据一致性。

使用只读副本模式，您的Greenplum数据库集群保持功能正常，可以处理只读查询，并继续执行持续恢复任务。只读副本模式支持以下操作：

• 在执行持续恢复任务的同时处理只读操作。
• 通过接受更改，使只读恢复集群与主集群保持同步。
• 在主集群发生故障时帮助恢复数据。
• 允许管理员监控复制状态，确保只读副本（恢复）集群与主集群保持同步。

启用只读副本模式

要启用只读副本模式，确保满足以下先决条件：

• Greenplum数据库7.3.0或更高版本
• 已应用完全或增量恢复的恢复集群
• 停止并禁用恢复集群上的任何计划的Greenplum灾难恢复恢复工作负载

当满足上述条件时，可以通过运行gpdr read-replica enable来启用只读副本模式。恢复集群必须随后通过gpstart启动。启动后，用户将能够运行只读查询。您还可以重新启动并启用恢复集群上的任何计划的Greenplum灾难恢复恢复工作负载。

禁用只读副本模式

要禁用只读副本模式，请通过gpstop停止恢复集群，然后运行gpdr read-replica disable。

允许的数据库命令

在只读副本模式下，所有连接都严格为只读。恢复集群上的数据只能通过恢复新的恢复点来操作。

在只读副本模式下启动的事务可以发出以下命令：

• 查询访问：SELECT, COPY TO
• 游标命令：DECLARE, FETCH, CLOSE
• 设置：SHOW, SET, RESET
• 事务管理命令：
  • BEGIN, END, ABORT, START TRANSACTION
  • SAVEPOINT, RELEASE, ROLLBACK TO SAVEPOINT
  • 异常块和其他内部子事务
• LOCK TABLE，但仅当显式处于以下模式时：ACCESS SHARE, ROW SHARE, 或 ROW EXCLUSIVE
• 计划和资源：PREPARE, EXECUTE, DEALLOCATE, DISCARD
• 插件和扩展：LOAD

查询和WAL重放冲突

当用户查询与持续恢复并行运行时，可能会发生冲突，从而导致查询终止。这是因为恢复集群需要应用WAL（预写日志），而这些WAL文件可能会引入与数据文件冲突的更改，且不能跳过这些更改。将WAL的应用延迟到冲突查询完成是不理想的，因为这会严重干扰持续恢复过程，并且无法预测冲突查询何时完成。以下是可能影响用户查询的已知冲突场景：

• 恢复一个恢复点，该恢复点删除了查询正在使用的表空间。
• 恢复一个恢复点，该恢复点删除了用户当前连接的数据库。
• 恢复一个恢复点，该恢复点包含清理WAL记录（如VACUUM）以删除查询所需的行。
• 恢复一个恢复点，该恢复点包含需要在查询中使用的对象上执行ACCESS EXCLUSIVE锁定的操作（例如：DROP TABLE，TRUNCATE，REINDEX，CLUSTER，VACUUM FULL，REFRESH MATERIALIZED VIEW，ALTER INDEX，ALTER TABLE）。

我们建议在没有查询运行或在业务影响最小的时段进行上述冲突情况下的持续恢复。

限制

在使用恢复集群上的只读副本模式时，管理员和用户应注意以下限制：

• 资源队列和资源组配置将从最后应用的备份或恢复点继承。当前不支持在恢复集群上修改配置。如果从持续恢复中恢复了新的资源队列或资源组，必须重新启动恢复集群才能使它们生效。
• 目前不支持Greenplum扩展和外部组件，如gpbackup、gpcopy和pxf。
• 目前只支持Greenplum核心工具：gpstart、gpstop和gpconfig。
• 查询与持续恢复并行运行时，可能会因为查询与正在重放的WAL之间的冲突而被自动取消。有关更多信息，请参见“查询和WAL重放冲突”部分。
• 只支持可重复读事务隔离级别。在启用只读副本模式时，将自动在恢复集群上设置此隔离级别。
• 在提升恢复集群时，所有现有查询将被终止。

连续工作流和增量工作流

灾难恢复中可用的两种工作流——连续工作流和增量工作流

增量恢复和连续恢复工作流都使用物理数据备份和恢复点（以及它们关联的 WAL 归档文件）组合来确保灾难或计划停机期间的数据安全。

每种工作流类型都有其优缺点，特别是在存储容量和备份/恢复性能要求方面。

增量恢复和连续恢复工作流都使用物理数据备份和恢复点（以及它们关联的 WAL 归档文件）组合来确保灾难或计划停机期间的数据安全。

增量工作流侧重于物理备份——包括完整备份和增量备份。而连续工作流则强调在频繁的时间间隔创建恢复点，以提高获取集群在停机前的准确状态的概率。

VMware 通常建议使用连续工作流而不是增量工作流，因为连续工作流在各方面都更加轻量：增量备份比创建恢复点占用更多的存储空间和时间。

与完整备份或增量备份相比，在主集群上创建恢复点既快速又极其轻量。因此，对于重点关注最佳 RTO 和/或 RPO 的灾难恢复用例，通常推荐使用此工作流。

备份会占用更多的存储空间和时间。因此，用户需要频繁地过期不再需要的旧备份。如果自上次备份以来积累了大量 WAL 归档文件，那么恢复到最新的恢复点可能需要相当长的时间。

选择增量恢复而非连续恢复的最有力理由是，如果您希望恢复集群在不处于活动恢复模式时仍然可用于查询。要使恢复集群可查询，需要提升集群并将其切换回恢复模式。

在增量工作流中，将提升的集群切换回恢复模式比在连续工作流中更加顺畅。

增量恢复

在增量恢复工作流中，您首先在主集群上进行完整备份，并根据所需的频率进行后续的增量备份。然后，只需执行增量恢复并传递与该备份相关的恢复点，您就可以在恢复集群上恢复特定的增量备份。

连续恢复

在连续恢复工作流中，您在主集群上进行完整的物理备份，并通过在主集群上创建恢复点来创建集群状态的后续快照。每次创建恢复点时，GPDR 会记录集群状态的快照。您可以根据需要以每 5 到 10 分钟的频率创建恢复点。

创建的恢复点越多，可供恢复的时间点就越多，因此您拥有的恢复点距离灾难发生的时间就越近的概率也越高。因此，通过创建更多恢复点，您可以优化数据安全性。

作为此工作流的一部分，您应该频繁运行 gpdr restore -t continuous --restore-point latest 命令。此命令会获取最新的恢复点，并将其关联的 WAL 归档文件恢复到恢复集群。这确保了恢复集群几乎始终与主集群保持同步。

• 一旦您将恢复集群提升为主集群（使其可用于查询或准备进行故障恢复回原主集群），将无法继续进行连续恢复工作流。您必须先执行增量恢复至所需的恢复点，然后才能恢复连续恢复工作流。

工作流场景

工作流场景

本节介绍了三种工作流场景：

1. 仅进行完整备份的增量恢复
2. 进行完整备份和多个增量备份的增量恢复
3. 连续工作流恢复

场景 1：仅进行完整备份的增量恢复

以下图表展示了在增量工作流中，用户仅进行一次完整备份而没有增量备份的时间线。

后续精彩内容已被站长无情隐藏，请输入验证码解锁本文！

验证码：

获取验证码： 请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。