概述
公司很多项目上使用了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 TRANSACTIONSAVEPOINT,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：增量恢复，包含完整备份和增量备份
在这个增量恢复工作流中，用户首先进行一次完整备份，然后进行三次增量备份。以下是该场景的时间线：
t1：完整备份
用户在主集群上执行完整备份。此时，GPDR开始将数据文件复制到存储库中。
在t1时，数据库的快照被保存，并且GPDR会创建一个恢复点记录，并将其写入最新的WAL归档文件中。
t2、t3、t4：增量备份
在t2时，用户执行第一次增量备份。该增量备份仅包含自t1以来发生的数据库变化。
增量备份将更新的数据库数据记录在新的WAL文件中，记录了从t1到t2之间的所有数据库事件。
在t3和t4时，用户依次进行第二次和第三次增量备份，每次增量备份都记录了从上次备份以来的数据库变化。
恢复过程
在恢复集群上，GPDR将首先恢复t1时的完整备份数据文件。
然后，GPDR依次恢复从t1到t2、t2到t3、t3到t4的增量WAL文件。
这样，通过重放WAL文件中的数据库事件，恢复集群的状态就可以恢复到t4时刻。
增量备份的优势和恢复策略：
存储效率：增量备份仅包含自上次备份以来的数据变化，因此占用的存储空间较少。
恢复时间：恢复过程可能需要依次应用多个增量备份文件，因此恢复时间会比仅依赖完整备份的恢复过程长一些。
通过这种增量备份方式，用户可以在确保数据安全性的同时减少存储空间需求，尤其适用于大型数据库环境，能够高效地管理存储和备份周期。
场景 3：连续恢复
在连续恢复的工作流中，用户首先进行一次完整备份，然后按照预定频率进行多个显式恢复点的创建。以下是该场景的时间线：
t1：完整备份
用户在主集群上执行完整备份。此时，GPDR开始将数据文件复制到存储库中。
在t1时，数据库的快照被保存，并且GPDR会创建一个恢复点记录，并将其写入最新的WAL归档文件中。
t2、t3、t4：创建显式恢复点
在t2时，用户创建第一个显式恢复点。每个恢复点捕获数据库在特定时刻的状态，GPDR会记录该时刻的WAL文件。
同样地，在t3和t4时，用户创建第二和第三个显式恢复点。每个恢复点都在数据库状态发生变化时创建，确保在灾难恢复时有更多的恢复点可供选择。
恢复过程
在恢复集群上，GPDR首先恢复t1时的完整备份数据文件。
然后，GPDR会应用从t1到t2、t2到t3、t3到t4之间的WAL归档文件（这些文件会将恢复点的数据恢复到最新的状态）。
通过应用这些恢复点的WAL文件，数据库会恢复到t4时的状态。
连续恢复的优势和恢复策略：
较短的恢复时间：由于每个恢复点记录数据库的状态，可以减少灾难发生后的恢复时间（RTO），并且更精确地恢复到发生灾难时的状态。
更高的数据安全性：通过频繁创建恢复点（通常每隔几分钟），确保在灾难发生时可以恢复到非常接近的时间点，从而优化数据保护（RPO）。
轻量级存储：与增量备份相比，恢复点的创建相对较轻量，不需要额外的大量存储空间，尤其适合在高频率备份需求下使用。
通过这种连续恢复的工作流，用户可以实现几乎实时的灾难恢复，同时优化恢复点的粒度，最大程度降低数据丢失风险。
在这个场景中，灾难恢复过程遵循连续恢复工作流，涉及隐式和显式的恢复点。以下是该过程的详细说明：
时间线：
t1: 完全备份
用户在 t1 启动了完全备份。GPDR 将物理数据文件复制到存储库中。备份完成后，GPDR 自动创建一个隐式恢复点 (RP1)，该恢复点记录了备份完成时数据库的状态。
t2, t3, t4: 显式恢复点
随着数据库的继续变化，用户在 t2、t3 和 t4 分别创建了三个显式恢复点：RP2、RP3 和 RP4。这些恢复点由用户手动创建，捕获了数据库在这些特定时间点的状态。
恢复过程：
在恢复过程中，以下步骤会发生：
从完全备份恢复
GPDR 从在 t1 进行的完全备份中恢复物理数据文件。这代表了备份完成时数据库的状态。
重放 WAL 文件
GPDR 会根据所有四个恢复点 (RP1、RP2、RP3 和 RP4) 的 WAL 存档文件来重放数据。这些 WAL 文件包含了在各自恢复点之间所做的数据库更改。
最终状态
在应用了来自 RP1 到 RP4 的 WAL 存档文件后，恢复集群的状态将恢复到 RP4（即最新的显式恢复点）的状态。
关键注意事项：
显式恢复点的时机：显式恢复点必须在完全备份完成之后才能创建，因为备份的物理数据必须在存储库中可用，才能创建显式恢复点。
总结
1、continuous是持续应用归档，若报错，可以做增量恢复后再做持续恢复（连续工作流是推荐的方式）
2、incr每次是基于全量做增量恢复
3、同步频率可以是每5到10分钟一次
4、复制库是无需mirror的
5、全备备份文件可以删除，但是元数据文件需要保留！！！且，若全备文件删除后，后续不能再进行增量备份了，强烈建议全备和增量备份的文件不要删！！！
6、不能跨大版本做灾备（例如，主GP6，备GP7）
7、若备库做了1次gpdr promote操作，则后续还想作为备库，则需要在主库做1次增量备份，然后再备库直接做还原即可：
1-- 增量同步（必须保留一次全备）
2gpdr backup --type incr
3gpdr restore -t incr --buffer-size 16MiB --process-max 4 --restore-point latest
8、日志文件：/home/gpadmin/gpAdminLogs/gpdr_20241229.log，子进程日志路径：/usr/local/gpdr/logs
9、若S3挂掉了，则主库正常，但是wal日志会堆积
10、1个主库可以挂多个备库，做两地三中心架构（即生产数据中心、同城灾备中心、异地灾备中心的高可用容灾方案），多同城多中心等。
缺点
1、GPDB 6不支持只读备库；GPDB 7支持只读备库，但是似乎有一些bug导致不能很好的应用wal
2、GPDB7备集群正在做还原的时候，备库不能查询
3、不能实时同步（需要配置同步频率，shell脚本控制）
4、备库不能使用gpcc
5、主和备的segment数必须一样
