PostgreSQL复制和备份的3种方法

梦里梦外; 2021-11-09 08:34 649阅读 0赞

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

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

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

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

## **PostgreSQL中复制的三种方法** ##

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

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

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

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

![aHR0cHM6Ly9hc2sucWNsb3VkaW1nLmNvbS9odHRwLXNhdmUvMzM5NTA1NS8yNGd6Y3BmcHpjLnBuZz9pbWFnZVZpZXcyLzIvdy8xNjIw][]

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

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

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

## **方法2：复制块设备** ##

![aHR0cHM6Ly9hc2sucWNsb3VkaW1nLmNvbS9odHRwLXNhdmUvMzM5NTA1NS92NjZqc2RwbGRyLnBuZz9pbWFnZVZpZXcyLzIvdy8xNjIw][]

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

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

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

![aHR0cHM6Ly9hc2sucWNsb3VkaW1nLmNvbS9odHRwLXNhdmUvMzM5NTA1NS9ibW5zMWNlY3lqLnBuZz9pbWFnZVZpZXcyLzIvdy8xNjIw][]

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

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

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

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

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

<table> 
 <thead> 
  <tr> 
   <th> <p>POSTGRES的类型</p> </th> 
   <th> <p>谁这样做？</p> </th> 
   <th> <p>主要好处</p> </th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td> <p>简单的流式复制 （本地磁盘）</p> </td> 
   <td> <p>本地 手册EC2</p> </td> 
   <td> <p>更易于设置 高I / O性能和大容量存储</p> </td> 
  </tr> 
  <tr> 
   <td> <p>复制块设备</p> </td> 
   <td> <p>RDS Azure Postgres</p> </td> 
   <td> <p>适用于MySQL，PostgreSQL 数据在云环境中的持久性</p> </td> 
  </tr> 
  <tr> 
   <td> <p>从WAL重建 （并切换到流复制）</p> </td> 
   <td> <p>Heroku Citus Cloud</p> </td> 
   <td> <p>后台节点重建 启用fork和PITR</p> </td> 
  </tr> 
 </tbody> 
</table>

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

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

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

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

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

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

欢迎关注技术公众号：架构师成长营

![2019080218172145.jpeg][]

[aHR0cHM6Ly9hc2sucWNsb3VkaW1nLmNvbS9odHRwLXNhdmUvMzM5NTA1NS8yNGd6Y3BmcHpjLnBuZz9pbWFnZVZpZXcyLzIvdy8xNjIw]: /images/20211109/dff3b8ef518e43509c3897521e131d3a.png
[aHR0cHM6Ly9hc2sucWNsb3VkaW1nLmNvbS9odHRwLXNhdmUvMzM5NTA1NS92NjZqc2RwbGRyLnBuZz9pbWFnZVZpZXcyLzIvdy8xNjIw]: /images/20211109/3c217d0cceb2406a8cc5013c2542ceac.png
[MySQL]: https://cloud.tencent.com/product/cdb?from=10680
[SQL Server]: https://cloud.tencent.com/product/sqlserver?from=10680
[aHR0cHM6Ly9hc2sucWNsb3VkaW1nLmNvbS9odHRwLXNhdmUvMzM5NTA1NS9ibW5zMWNlY3lqLnBuZz9pbWFnZVZpZXcyLzIvdy8xNjIw]: /images/20211109/11721a878c0c495b953308df2f450b4d.png
[Link 1]: https://www.citusdata.com/blog/2017/03/23/a-look-into-disaster-recovery-and-high-availability-and-how-they-work-with-postgres-on-citus-cloud/
[Link 2]: https://www.citusdata.com/blog/2017/08/04/fork-your-distributed-postgres-with-citus-cloud/
[2019080218172145.jpeg]: https://img-blog.csdnimg.cn/2019080218172145.jpeg