PostgreSQL已经证明了自己的价值-它的功能非常强大，已被阿里巴巴和TripAdvisor之类的新兴数字业务所使用，而且由于没有使用费，它成为了MS SQL或Oracle DB等庞然大物的诱人替代品。但是，一旦我们开始在企业环境中考虑PostgreSQL，就会立即遇到严格的要求：“但是，配置容错又如何呢？抗灾能力？综合监测在哪里？自动备份呢？使用磁带库（直接存储和辅助存储）如何？”
一方面，PostgreSQL没有内置的备份工具，例如“成人” DBMS，例如用于Oracle DB的RMAN或SAP Database Backup。另一方面，公司备份系统（Veeam，Veritas，Commvault）的供应商虽然支持PostgreSQL，但实际上仅在某些（通常是独立的）配置和一组各种限制下工作。
专为PostgreSQL设计的备份系统，例如Barman，Wal-g，pg_probackup，在小型PostgreSQL安装中或不需要大量IT领域其他元素的备份的情况下非常流行。例如，除了PostgreSQL外，基础架构还可以具有物理和虚拟服务器，OpenShift，Oracle，MariaDB，Cassandra等。所有这些都应使用通用工具进行备份。专门为PostgreSQL放置一个单独的解决方案是一个坏主意：将数据复制到磁盘上的某个位置，然后将它们删除到磁带上。备份的这种重复增加了备份时间，更重要的是恢复了时间。
在企业解决方案中，在专用群集中使用一定数量的节点来备份安装。同时，例如，Commvault只能与两节点群集一起使用，在该群集中，“主要”和“辅助”被严格分配给某些节点。而且仅使用Primary进行备份是有意义的，因为使用Secondary进行备份有其局限性。由于DBMS的特殊性，不会在辅助数据库上创建转储，因此仅保留了文件备份的可能性。
为了降低停机风险，创建容错系统将创建活动集群配置，并且Primary可以在不同服务器之间逐步迁移。例如，Patroni软件本身会在随机选择的群集节点上启动Primary。 SRK无法立即跟踪它，并且如果配置发生更改，则过程会中断。也就是说，引入外部控制会阻止SRK有效工作，因为控制服务器根本不了解需要从何处复制哪些数据。
另一个问题是Postgres中的备份实现。可以通过转储实现，并且可以在较小的基础上运行。但是在大型数据库中，转储会花费很长时间，需要大量资源，并且可能导致数据库实例失败。
文件备份可以纠正这种情况，但是在大型数据库上，它很慢，因为它可以在单线程模式下工作。此外，供应商还有许多其他限制。您不能同时使用文件和转储备份，或者不支持重复数据删除。存在许多问题，通常更容易选择昂贵但经过验证的DBMS代替Postgres。
无处可退！在莫斯科开发商的背后！
但是，最近，我们的团队面临着一个艰巨的挑战：在创建AIS OSAGO 2.0的项目（我们在此建立IT基础架构）中，新系统的开发人员选择了PostgreSQL。
对于大型软件开发人员而言，使用“时尚”开源解决方案要容易得多。Facebook有足够的专家来支持此DBMS的工作。对于PCA，“第二天”的所有任务都落在我们肩上。我们被要求提供容错能力，组装一个集群，当然还要建立一个备份。动作的逻辑如下：
- 教SRK从群集的主节点进行备份。为此，SRK必须找到它，这意味着它需要与一种或另一种解决方案集成以管理PostgreSQL集群。在PCA的情况下，使用Patroni软件。
- 根据数据量和恢复要求确定备份类型。例如，当需要精细地还原页面时，请使用转储，并且如果数据库很大并且不需要精细还原，请在文件级别进行。
- 将块备份功能附加到解决方案以创建多线程备份。
同时，我们最初着手创建一个有效而简单的系统，而不会因附加组件而造成不必要的麻烦。拐杖越少，工作量就越少，IBS故障的风险也就越低。我们立即排除了使用Veeam和RMAN的方法，因为两种解决方案已经暗示了系统的不可靠性。
企业的魔力
因此，我们需要确保对每个3个节点的10个群集进行可靠的备份，同时在备份数据中心中镜像相同的基础架构。 PostgreSQL计划中的数据中心采用主动-被动原则。数据库的总大小为50 TB。任何公司级别的SRC都可以轻松地处理此问题。但是，细微差别在于，Postgres最初并不具有与备份系统完全和深度兼容性的钩子。因此，我们必须寻找一种最初具有与PostgreSQL结合使用的最大功能的解决方案，并完善系统。
我们进行了3次内部“黑客马拉松”-我们研究了五十多个开发项目，对其进行了测试，对假设进行了更改，然后再次进行了测试。在分析了可用选项之后，我们选择了Commvault。开箱即用，该产品可以与最简单的群集PostgreSQL安装一起使用，其开放式体系结构为成功进行完善和集成带来了希望（实现了）。 Commvault也可以备份PostgreSQL日志。例如，PostgreSQL部分中的Veritas NetBackup仅能进行完整备份。
了解有关架构的更多信息。 Commvault管理服务器以CommServ HA配置安装在两个数据中心的每一个中。该系统是通过单个控制台进行镜像，管理的，并且从HA的角度来看，它可以满足所有企业要求。
我们还在每个数据中心启动了两个物理介质服务器，将专用于通过光纤通道通过SAN进行备份的磁盘阵列和磁带库连接到了这两个物理介质服务器。扩展的重复数据删除基础确保了媒体服务器的弹性，并且将每个服务器连接到每个CSV可以确保在任何组件出现故障的情况下持续运行。该系统的体系结构允许备份继续进行，即使其中一个数据中心发生故障也是如此。
Patroni为每个群集定义一个主节点。它可以是数据中心中的任何空闲节点-但只能在主节点上。在备份中，所有节点都是辅助节点。
为了使Commvault了解哪个群集节点是主要的，我们将系统（由于解决方案的开放式体系结构）与Postgres集成在一起。为此，创建了一个脚本，该脚本向Commvault管理服务器报告主节点的当前位置。
通常，该过程如下所示：
Patroni选择Primary→Keepalived打开IP群集并运行脚本→群集的选定节点上的Commvault代理收到一个通知，通知它是Primary→Commvault自动在伪客户端中重新配置备份。
这种方法的优点是解决方案不会影响日志的一致性或正确性，也不会影响Postgres实例的恢复。它也易于扩展，因为现在不必为Commvault修复主节点和辅助节点。系统了解主节点在哪里就足够了，节点数可以增加到几乎任何值。
该解决方案并不假装是理想的，并且有其细微差别。 Commvault只能备份整个实例，而不能备份单个数据库。因此，已经为每个数据库创建了一个单独的实例。真实客户端被组合为虚拟伪客户端。每个Commvault伪客户端都是UNIX群集。它将添加安装了Commvault for Postgres代理的那些群集节点。结果，将伪客户端的所有虚拟节点备份为一个实例。
在每个伪客户端中，指示群集的活动节点。这就是我们为Commvault定义的集成解决方案。其操作原理非常简单：如果群集IP在某个节点上上升，则脚本将在Commvault代理二进制文件中设置“活动节点”参数-实际上，脚本在内存的所需部分中设置为“ 1”。代理将该数据发送到CommServe，然后Commvault从所需节点进行备份。另外，在脚本级别检查配置的正确性，有助于避免在开始备份时出错。
同时，大型数据库在多个线程中按块进行备份，从而满足RPO和备份窗口的要求。系统上的负载微不足道：全副本不会经常发生，在其他日子里，仅在低负载期间才收集日志。
顺便说一句，我们为备份PostgreSQL归档日志应用了单独的策略-它们根据不同的规则存储，根据不同的时间表进行复制，并且由于这些日志包含唯一数据，因此未对其启用重复数据删除。
为了确保整个IT基础结构的一致性，在每个群集节点上都安装了单独的Commvault文件客户端。它们从备份中排除Postgres文件，仅用于OS和应用程序备份。数据的这部分还具有自己的策略和自己的存储期限。
现在，SRK不会影响生产服务，但是如果情况发生变化，则可以在Commvault中启用负载限制系统。
好吗？好！
因此，我们不仅为群集的PostgreSQL安装提供了可行的备份，而且还提供了全自动备份，可以满足企业调用的所有要求。
RPO和RTO参数在1小时和2小时处有一个边距重叠，这意味着即使存储数据量显着增加，系统也将匹配它们。尽管存在许多疑问，PostgreSQL和企业环境是完全兼容的。现在，根据我们自己的经验，我们知道可以在多种配置中备份此类DBMS。
当然，在此过程中，我们必须穿破七双铁靴，克服许多困难，踩几把耙子并纠正许多错误。但是现在，该方法已经过测试，可以在恶劣的企业环境中用于实现开源而不是专有的DBMS。
您是否在公司环境中尝试过PostgreSQL？
作者：
Oleg Lavrenov，Jet信息系统数据存储系统
设计工程师Dmitry Erykin，Jet信息系统计算系统设计工程师