PostgreSQL数据库遵循简单的复制模型。在此模型中,所有写入都将转到主节点。然后,主节点在本地应用这些更改并将它们传播到辅助节点。
在Postgres的上下文中,内置复制(称为“流复制”)带来了一些挑战:
- Postgres复制没有内置监视和故障转移。当主节点发生故障时,您需要将辅助节点提升为新的主节点。此促销需要以客户端仅写入一个主节点的方式进行,并且不会观察到数据不一致。
- 许多Postgres客户端(用不同的编程语言编写)与单个端点进行通信。当主节点发生故障时,这些客户端将继续重试相同的IP或DNS名称。这使得应用程序可以看到故障转移。
- Postgres复制了整个状态。当您需要构建新的辅助节点时,辅助节点需要从主节点重放状态更改的整个历史记录。这个过程是资源密集型的 - 并且使得杀死头部中的节点并引发新节点变得昂贵。
前两个挑战是很好理解的。由于上一次挑战并未得到广泛认可,我们将在此博客文章中对其进行检查。
PostgreSQL中复制的三种方法
大多数人认为,当您拥有主要和次要架构时,只有一种方法可以设置复制和备份。在实践中,Postgres部署遵循三种方法之一。
- PostgreSQL流复制将数据从主节点复制到辅助节点。备份到S3 / Blob存储。
- 要在存储层从主节点复制到辅助节点的volume级别复制。备份到S3 / Blob存储。
- 从主节点到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复制的这些不同方法如何比较?
这是一个简单的表格,将这些方法相互比较。对于每种方法,您可以将其益处视为其他方法的缺点。
POSTGRES的类型 | 谁这样做? | 主要好处 |
---|---|---|
简单的流式复制 (本地磁盘) | 本地 手册EC2 | 更易于设置 高I / O性能和大容量存储 |
复制块设备 | RDS Azure Postgres | 适用于MySQL,PostgreSQL 数据在云环境中的持久性 |
从WAL重建 (并切换到流复制) | Heroku Citus Cloud | 后台节点重建 启用fork和PITR |
简单的流式复制是最常用的方法。大多数本地部署都遵循这种方法。它很容易设置。此外,使用本地磁盘进行设置时,可以存储10个TB的数据。
相比之下,磁盘镜像方法从数据库中抽象出存储层。在这种方法中,当你丢失一个实例时,你不会丢失你的短暂磁盘。这种方法也适用于数据库技术,例如MySQL和Postgres。
在第三种方法中,当您拥有一台新机器时,可以从WAL日志重建该机器的状态。由于您将WAL日志视为一等公民,因此某些功能变得微不足道。例如,假设您希望针对生产数据对应用程序进行性能测试,而不是针对生产数据库进行性能测试。在第三种方法中,您可以在WAL日志中从特定时间点“分叉”数据库,而不会影响生产,并针对分叉数据库测试您的应用程序。
哪种PostgreSQL复制方法更“云原生”?
PostgreSQL带有三种不同的复制方法。与许多事情一样,每种复制方法都有其优点和缺点。
第三种方法通过从blob存储(例如S3)重放预写日志(WAL)来重建新的辅助节点。因此,重建新副本不会在主节点上引入任何额外负载。这使得高可用性(HA)解决方案成为可以轻松启动或击落数据库节点的解决方案 - 这一特性在云原生环境中非常有用。
欢迎关注技术公众号:架构师成长营