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