写点什么

PostgreSQL 高可用:多主复制解决方案

发布于: 2020 年 12 月 18 日

作者:伊布拉尔·艾哈迈德(Ibrar Ahmed)在 2018 年 7 月加入 Percona。在加入 Percona 之前,Ibrar 曾在 EnterpriseDB 担任高级数据库架构师 10 年。Ibrar 拥有 18 年的软件开发经验。Ibrar 在 PostgreSQL 上写了多本书。

 

译者:魏波,中国 PG 分会培训认证执行总监、资深数据库工程师,十多年的数据库运维管理及培训经验,掌握 PostgreSQL 架构部署、性能优化等,致力于推动 PostgreSQL 在中国的发展。

 

由于数据量巨大,因此可伸缩性已成为数据库领域中最热门的主题之一。可伸缩性可以水平或垂直实现。垂直可伸缩性意味着向现有节点添加更多资源/硬件,以增强数据库存储和处理更多数据的能力,例如,向现有节点添加 CPU,内存或磁盘。每个 DBMS 引擎都通过改进锁定/互斥机制和并发性,从而可以更有效地使用新添加的资源,从而提高了垂直可伸缩性的能力。数据库引擎提供配置参数,这有助于更有效地利用可用的硬件资源。 

 

由于硬件成本以及在现有节点中添加新硬件的限制,因此并非总是可以添加新硬件。因此,需要水平可伸缩性,这意味着向现有网络节点添加更多节点而不是增强现有节点的功能。

与垂直可伸缩性相反,水平可伸缩性难以实施。这需要更多的开发工作。

 

PostgreSQL 为垂直可伸缩性和水平可伸缩性提供了相当丰富的功能集。它支持具有多个处理器和大量内存的计算机,并提供配置参数来管理这些资源的使用。PostgreSQL 中并行性的新功能使垂直可伸缩性更加突出,但也不缺乏水平可伸缩性。复制是水平可伸缩性的关键支柱,PostgreSQL 支持单向主从复制,这足以满足许多用例。 

 

关键概念

数据库复制

数据库复制将数据复制到其他服务器上,并将其存储在多个节点上。在此过程中,数据库实例从一个节点转移到另一节点,并进行了精确的复制。数据复制用于提高数据可用性,这是 HA 的一项关键功能。通常有一个完整的数据库实例,或者一些经常使用或所需的对象被复制到另一台服务器。复制提供了数据库的多个一致副本,它不仅提供了高可用性,而且还提高了查询性能。 

 

同步复制

将数据写入磁盘时,有两种策略:“同步”和“异步”。同步复制意味着同时将数据写入主服务器和从服务器,换句话说,“同步复制”意味着提交等待远程端的写入/刷新。同步复制用于具有即时故障转移要求的高端事务环境中。

 

异步复制

异步意味着首先将数据写入主机,然后再复制到从机。在崩溃的情况下,可能会发生数据丢失,但是异步复制提供的开销很小,因此在大多数情况下是可以接受的。它不会使主机负担过重。与同步复制相比,从主数据库到从数据库的故障转移需要更长的时间。 

简而言之,同步和异步之间的主要区别在于何时将数据写入主服务器和从服务器。 

 

单主复制

单一主复制意味着仅允许在单个节点上修改数据,并将这些修改复制到一个或多个节点。只能在主节点上进行数据更新和插入。在这种情况下,应用程序需要将流量路由到主服务器,这会增加应用程序的复杂性。因为只有一个主节点负责写入数据,所以没有冲突的机会。在大多数情况下,单主复制对于应用程序来说就足够了,因为配置和管理起来并不那么复杂。但在某些情况下,单主复制是不够的,您需要多主复制。

 

多主复制 

多主复制意味着有多个节点充当主节点。数据在节点之间复制,并且可以在一组主节点上进行更新和插入。在这种情况下,数据有多个副本。该系统还负责解决并发更改之间发生的任何冲突。有多个主复制有两个主要原因。一个是高可用性,第二个是性能。在大多数情况下,某些节点专用于密集写入操作,而某些节点专用于某些节点或用于故障转移。  

 

多主复制的优缺点

优点:

  • 万一一个主机发生故障,另一个主机仍然能提供更新和插入服务。 

  • 主节点位于几个不同的位置,因此所有主节点发生故障的机会非常小。

  • 可以在多台服务器上进行数据更新。

  • 应用程序不需要将流量仅路由到单个主机。


缺点:

  • 多主复制的主要缺点是它的复杂性。 

  • 解决冲突非常困难,因为可以同时在多个节点上进行写操作。

  • 有时在发生冲突的情况下需要人工干预。

  • 数据不一致的可能性。


正如我们已经讨论的那样,在大多数情况下,单主复制就足够了,强烈建议这样做,但是在某些情况下,仍然需要多主复制。PostgreSQL 具有内置的单主复制,但不幸的是,PostgreSQL 主版本中没有多主复制。有一些可用的多主复制解决方案,其中一些以应用程序的形式出现,而有些则是 PostgreSQL 分支。这些派生有其自己的小型社区,并且大多由单个公司管理,而不由 PostgreSQL 国际社区管理。 

这些解决方案有多种类别,包括开放源/封闭源,优先级,免费和付费。 

  • BDR(双向复制)

  • xDB

  • PostgreSQL-XL

  • PostgreSQL-XC / PostgreSQL-XC2

  • Rubyrep

  • Bucardo


这是所有复制解决方案的一些关键功能


1. BDR(双向复制)

BDR 是多主复制解决方案,并且具有不同的版本。BDR 的早期版本是开放源代码,但其最新版本是封闭源代码。这个解决方案是由 2ndQuadrant 开发的,也是迄今为止最优雅的多主解决方案之一。BDR 提供异步多主逻辑复制。这基于 PostgreSQL 逻辑解码功能。  由于 BDR 应用实质上是在其他节点上重播事务,因此如果正在应用的事务与在接收节点上提交的事务之间存在冲突,则重播操作可能会失败。


2. xDB

EnterpriseDB 用 Java 开发了自己的双向复制解决方案,称为 xDB。它基于自己的协议。因为它是一个封闭源代码的解决方案,所以没有设计信息为外界所知。

  • 由 EnterpriseDB 开发和维护。

  • 用 Java 开发。

  • 源代码是封闭源代码。

  • xDB Replication Server 包含多个可执行程序。

  • 这是一个完全封闭源代码的专有软件。

  • 用 Java 开发,大家会抱怨它的性能。

  • 故障转移时间是不可接受的。

  • 用户界面可用于配置和维护复制系统。


3. PostgreSQL XC / XC2

PostgreSQL-XC 由 EnterpriseDB 和 NTT 开发。它是一个同步复制解决方案。Postgres-XC 是一个开源项目,旨在提供可写扩展、同步、对称和透明的 PostgreSQL 集群解决方案。多年来,我从未在 EnterpriseDB 和 NTT 上看到 PostgreSQL-XC 的大量开发。目前,华为正在为此努力。对于 OLAP,已经报告了一些性能提升,但不适用于 TPS。

 

4. PostgreSQL XL

它是 PostgreSQL-XC 的一个分支,目前受 2ndQuadrant 支持。它会落后于社区 PostgreSQL 的版本迭代。据了解,它基于 PostgreSQL 10.6,它与 PostgreSQL 最新版本 PostgreSQL-12 不兼容。我们知道它是基于 PostgreSQL-XC 的,当我们谈论 OLAP 时,它非常好,但不太适合高 TPS。

注意:所有 PostgreSQL XC / XC2 / XL 都被认为是“ PostgreSQL 衍生软件”,与 PostgreSQL 的当前开发没有同步。

 

5. Rubyrep

它是阿恩.特莱曼(Arndt Lehmann)开发的异步主/主复制。它声称具有最简单的配置特征,并且可以跨平台(包括 Windows)运行。它始终在两台服务器上运行,在 Rubyrep 术语中分别称为“左”和“右”。因此,将其称为“2-master”设置而不是“ multi-master”会更符合其特点。 

  • rubyrep 可以在左右数据库之间连续复制更改。

  • 自动设置必要的触发器,日志表等

  • 自动发现新添加的表并同步表内容

  • 自动重新配置序列,以避免重复的键冲突

  • 跟踪对主键列的更改

  • 可以同时实现主从复制

  • 提供预先建立的冲突解决方法:左/右获胜;早/晚更改胜出

  • 可通过 ruby 代码段指定自定义冲突解决方案

  • 复制决定可以有选择地记录在 rubyrep 事件日志表中

 

注意:–就开发而言,该项目在过去三年中一直没有开展。

 

6. Bucardo 

Bucardo 是 End Point 公司的 Jon Jensen 和 Greg Sabino Mullane 开发的基于触发器的复制解决方案。Bucardo 的解决方案已经存在了将近 20 年,最初设计为“惰性”异步解决方案,最终可以复制所有更改。有一个 Perl 守护程序,它监听 NOTIFY 请求并对其执行操作。表上发生的更改记录在表(bucardo_delta)中,并通知守护程序。守护程序通知控制器,该控制器启动一个子进程以同步表更改。如果存在冲突,则使用标准或自定义冲突处理程序进行处理。

  • 基于触发器的复制

  • 有解决冲突策略

  • 对 Perl 5,DBI,DBD :: Pg,DBIx :: Safe 的依赖。

  • 安装和配置很复杂。

  • 复制经常中断并且出现错误。


结论

单主机复制的大多数情况就足够了,并且已经观察到人们正在配置多主机复制并使他们的设计过于复杂。强烈建议设计系统,并尝试避免多主复制,而仅在没有其他方法的情况下使用它。原因有两个:第一,它使系统过于复杂且难以调试;第二,由于没有可用的社区维护的多主复制,因此您将无法从 PostgreSQL 社区获得支持。

 

原文链接:

https://www.percona.com/blog/2020/06/09/multi-master-replication-solutions-for-postgresql/


更多精彩内容,请关注以下平台、网站:

 

中国 Postgre SQL 分会官方公众号(技术文章、技术活动):

开源软件联盟 PostgreSQL 分会


中国 Postgre SQL 分会技术问答社区:

www.pgfans.cn


中国 Postgre SQL 分会官方网站:

www.postgresqlchina.com

发布于: 2020 年 12 月 18 日阅读数: 111
用户头像

开源是一种商业模式适合于中国 2020.10.31 加入

官方公众号:开源软件联盟PostgreSQL分会 官方网站:postgresqlchina.com 官方交流社区:pgfans.cn 官方资源社区:postgreshub.cn

评论

发布
暂无评论
PostgreSQL高可用:多主复制解决方案