PostgreSQL复制和备份的3种方法

Citus分布式数据库通过拆分，复制和查询并行扩展了PostgreSQL的。对于复制，我们的数据库即服务（默认情况下）利用Postgres内置的流复制逻辑。

当我们与Citus用户交谈时，我们经常会听到有关设置Postgres高可用性（HA）群集和管理备份的问题。你如何处理复制和机器故障？在设置Postgres HA时遇到了哪些挑战？

PostgreSQL数据库遵循简单的复制模型。在此模型中，所有写入都将转到主节点。然后，主节点在本地应用这些更改并将它们传播到辅助节点。

在Postgres的上下文中，内置复制（称为“流复制”）带来了一些挑战：

• Postgres复制没有内置监视和故障转移。当主节点发生故障时，您需要将辅助节点提升为新的主节点。此促销需要以客户端仅写入一个主节点的方式进行，并且不会观察到数据不一致。
• 许多Postgres客户端（用不同的编程语言编写）与单个端点进行通信。当主节点发生故障时，这些客户端将继续重试相同的IP或DNS名称。这使得应用程序可以看到故障转移。
• Postgres复制了整个状态。当您需要构建新的辅助节点时，辅助节点需要从主节点重放状态更改的整个历史记录。这个过程是资源密集型的 - 并且使得杀死头部中的节点并引发新节点变得昂贵。

前两个挑战是很好理解的。由于上一次挑战并未得到广泛认可，我们将在此博客文章中对其进行检查。

PostgreSQL中复制的三种方法

大多数人认为，当您拥有主要和次要架构时，只有一种方法可以设置复制和备份。在实践中，Postgres部署遵循三种方法之一。

1. PostgreSQL流复制将数据从主节点复制到辅助节点。备份到S3 / Blob存储。
2. 要在存储层从主节点复制到辅助节点的volume级别复制。备份到S3 / Blob存储。
3. 从主节点到S3进行增量备份。从S3重建新的辅助节点。当辅助节点足够接近主节点时，从主节点开始流式传输。

还有一种简单的方法可以确定您正在使用哪种方法。假设您添加了一个新的辅助节点。如何重建新的辅助节点的状态？

方法1：PostgreSQL中的流复制（使用本地存储）

第一种方法是最常见的方法。你有一个主节点。主节点具有表的数据和预写日志（WAL）。（当您修改Postgres中的行时，更改首先会被提交到仅附加重做日志。此重做日志称为预写日志或WAL。）然后，此Postgres WAL日志将流式传输到辅助节点。

在第一种方法中，当您构建新的辅助节点时，新的辅助节点需要从主节点重播整个状态 - 从时间开始。然后，重放操作可能在主节点上引入显着负载。如果数据库的主节点提供实时流量，则此负载变得更加重要。

在此方法中，您可以使用本地磁盘或将持久volume附加到实例。在上图中，我们使用的是本地磁盘，因为这是更典型的设置。

方法2：复制块设备

第二种方法依赖于磁盘镜像（有时称为volume复制）。在此方法中，更改将写入持久volume。然后，此volume将同步镜像到另一个volume。这种方法的好处是它适用于所有关系数据库。您可以将它用于MySQL，PostgreSQL或SQL Server。

但是，Postgres中的磁盘镜像复制方法还要求您复制表和WAL日志数据。此外，现在每次写入数据库都需要同步通过网络。您不能错过任何一个字节，因为这可能会使您的数据库处于损坏状态。

方法＃3：从WAL重建（并切换到流复制）

第三种方法将复制和灾难恢复过程彻底改变。您写入主节点。主节点每天执行完整数据库备份，每60秒执行一次增量备份。

当您需要构建新的辅助节点时，辅助节点会从备份重建其整个状态。这样，您不会在主数据库上引入任何负载。您可以启动新的辅助节点并从S3 / Blob存储重建它们。当辅助节点足够接近主节点时，您可以从主节点开始流式传输WAL日志并赶上它。在正常状态下，辅助节点跟随主节点。

在这种方法中，预写日志优先。这种设计适用于更加云原生的架构。您可以随意调出或击落副本，而不会影响关系数据库的性能。您还可以根据需要使用同步或异步复制。

Postgres复制的这些不同方法如何比较？

这是一个简单的表格，将这些方法相互比较。对于每种方法，您可以将其益处视为其他方法的缺点。

简单的流式复制是最常用的方法。大多数本地部署都遵循这种方法。它很容易设置。此外，使用本地磁盘进行设置时，可以存储10个TB的数据。

相比之下，磁盘镜像方法从数据库中抽象出存储层。在这种方法中，当你丢失一个实例时，你不会丢失你的短暂磁盘。这种方法也适用于数据库技术，例如MySQL和Postgres。

在第三种方法中，当您拥有一台新机器时，可以从WAL日志重建该机器的状态。由于您将WAL日志视为一等公民，因此某些功能变得微不足道。例如，假设您希望针对生产数据对应用程序进行性能测试，而不是针对生产数据库进行性能测试。在第三种方法中，您可以在WAL日志中从特定时间点“分叉”数据库，而不会影响生产，并针对分叉数据库测试您的应用程序。

哪种PostgreSQL复制方法更“云原生”？

PostgreSQL带有三种不同的复制方法。与许多事情一样，每种复制方法都有其优点和缺点。

第三种方法通过从blob存储（例如S3）重放预写日志（WAL）来重建新的辅助节点。因此，重建新副本不会在主节点上引入任何额外负载。这使得高可用性（HA）解决方案成为可以轻松启动或击落数据库节点的解决方案 - 这一特性在云原生环境中非常有用。

原文标题《3 Approaches to PostgreSQL Replication and Backup》

作者：Ozgun Erdogan

译者：February

不代表云加社区观点，更多详情请查看原文链接