软件目录 - 集群/复制

作为 BiSoft 团队，多年来一直为众多公共和私人机构提供 PostgreSQL 支持，我们重视 PostgreSQL 在我们国家和世界范围内的传播，并提高其效率。凭借我们持续的 PostgreSQL 管理经验，根据我们看到的需求，我们现在满足了高级自动故障转移和审计的需求。我们很高兴宣布我们为满足这些需求而开发的软件。一旦数据库环境安装完毕，首先想到的事情之一就是数据访问的连续性和可持续性 (HA)。在 PostgreSQL 中，HA 是通过内置的复制解决方案提供的。没有基于共享存储逻辑的多主架构。在复制环境中，如果主服务器发生故障，则应将备用服务器中最合适的服务器指定为新的主服务器，并且如果有任何其他备用服务器，则应将其定向到新的主服务器。这些操作需要手动干预或可以自动执行这些操作的外部工具。BFM 在 PostgreSQL 中自动执行所有这些操作，并在故障转移期间提供不间断的服务。

用于 Postgres 的多主和多从异步复制系统。

CloudNativePG 是一个开源 Operator，旨在管理在任何受支持的 Kubernetes 集群上运行的 PostgreSQL 工作负载，无论该集群是在私有云、公有云、混合云还是多云环境中运行。CloudNativePG 遵循 DevOps 原则和概念，例如声明式配置和不可变的基础架构。

它定义了一个新的 Kubernetes 资源，称为 Cluster，它代表一个 PostgreSQL 集群，该集群由一个主节点和可选的多个副本组成，这些副本在选定的 Kubernetes 命名空间中共存，以实现高可用性并卸载只读查询。

位于同一 Kubernetes 集群中的应用程序可以使用仅由 operator 管理的服务访问 PostgreSQL 数据库，而无需担心故障转移或切换后主角色发生变化。位于 Kubernetes 集群外部的应用程序需要配置一个服务或 Ingress 对象，以通过 TCP 公开 Postgres。Web 应用程序可以利用基于 PgBouncer 的原生连接池。

CloudNativePG 最初由 EDB 构建，然后在 Apache 许可证 2.0 下发布为开源，并于 2022 年 4 月提交给 CNCF 沙箱。源代码存储库在 Github 中。

Tungsten Enterprise 是一个完整的 PostgreSQL 复制和数据管理解决方案。Tungsten Enterprise 使用复制和分布式管理来创建使用冗余数据副本的虚拟化数据库。Tungsten Enterprise 帮助客户构建容错集群，以确保不间断地访问数据、提高性能并降低成本。最重要的是，Tungsten 不需要 DBMS 升级或应用程序更新即可使用。它可以与现有应用程序和数据库版本透明地工作。

Tungsten Enterprise 基于 Tungsten Replicator 构建，这是一个用于 PostgreSQL 的开源数据复制引擎。Tungsten Enterprise 包括分布式管理，其中包含简单的 operator 命令来查看状态和执行维护、执行故障转移过程的业务规则、透明的 SQL 路由和负载平衡，以及与 NetApp 等高端存储系统的集成。Tungsten Enterprise 在云端和本地硬件上运行效果都很好。

Tungsten Enterprise 的客户包括大型企业、SaaS 企业、社交网站和 ISP。依赖 Tungsten Enterprise 的应用程序范围从内部 IT 系统到每天为数千个客户处理数亿笔交易的多租户应用程序。

EDB Postgres for Kubernetes 是一个由 EDB 设计、开发和支持的 operator，它涵盖了具有主/备架构的高可用性 Postgres 数据库集群的整个生命周期，使用原生流复制。它基于开源的 CloudNativePG operator，并提供了额外的价值，例如使用 EDB Postgres Advanced Server 与 Oracle 的兼容性以及其他受支持的平台，例如 IBM Power 和 OpenShift。

可用的主要功能包括：- 用于高可用性的 Kubernetes API 集成 - 通过故障转移和自动重新创建副本来实现自我修复 - 具有向上/向下扩展功能的容量管理 - 用于计划维护的计划切换 - 只读和读写 Kubernetes 服务定义 - 用于 Postgres 次要版本和 operator 升级的滚动更新 - 连续备份和时间点恢复 - 使用 PgBouncer 的连接池 - 开箱即用的集成指标导出器 - 跨多个 Kubernetes 集群的 PostgreSQL 复制 - 用于 OpenShift 的 Red Hat 认证 operator

该 operator 已从 Cloud Native PostgreSQL 重命名。Cloud Native PostgreSQL 的现有用户不会有任何变化，因为底层组件和资源没有变化。

GridSQL 是一个无共享的集群数据库系统，目标是数据仓库和数据集市应用程序。它包括在多个服务器上最大限度地并行化的智能，从而提供比单节点数据库更快的查询响应时间。

Kubegres 是一个 Kubernetes operator，允许开箱即用地部署启用了数据复制的 PostgreSql 实例集群。考虑到使用 Kubernetes 管理有状态集的生命周期和数据复制的复杂性，它在使用 PostgreSql 时带来了简单性。

Kubegres 具有以下功能

• 它创建一个启用了数据复制的 PostgreSql 服务器集群：它创建一个主 PostgreSql pod 和多个副本 PostgreSql pod，并将主数据库实时复制到副本 pod。

• 它管理故障转移：如果主 PostgreSql 崩溃，它会自动将副本 PostgreSql 提升为主节点。

• 它有一个数据备份选项，允许将 PostgreSql 数据定期转储到给定卷中。

• 它提供了一个非常简单的 YAML，其中包含专门为 PostgreSql 设计的属性。

• 它具有弹性，具有 55 多个自动化测试用例，并且已经在生产中运行。

• 它与 Docker 官方映像团队创建的 PostgreSql 容器一起使用：它不附带也不需要自定义 Docker 映像才能工作。

Kubegres 由 Reactive Tech Limited 和首席开发人员 Alex Arica 开发。

它是使用 Kubebuilder 版本 3 框架开发的，Kubebuilder 是一个用于使用 CRD 构建 Kubernetes API 的 SDK。Kubebuilder 由官方 Kubernetes API Machinery 特殊兴趣小组 (SIG) 维护。

您可以在入门页面中找到有关如何安装和使用的更多详细信息

Pervasync 数据库同步框架支持本地 PostgreSQL 数据库与中央 PosrgreSQL 数据库的同步。

该框架的标志性功能是它允许您使用带有参数的自由格式 SQL 查询来子集中央服务器数据。每个本地数据库都可以与中央数据库同步共享数据以及私有数据。

同步可以是双向的，这意味着可以在本地和中央数据库上进行写入。变更捕获、冲突检测和解决都内置在同步框架的核心中。

pg_auto_failover 是一个 PostgreSQL 扩展和服务，用于监视和管理 Postgres 集群的自动故障转移。它针对简单性和正确性进行了优化，并支持 Postgres 10 及更高版本。

pg_auto_failover 支持多种 Postgres 架构，并为您的 Postgres 服务实现安全的自动故障转移。您可以使用仅两个数据节点开始，监视器将为它们指定主角色和辅助角色。从 pg_auto_failover 1.4 版本开始，可以使用任意数量的 Postgres 节点来实现生产架构，以获得更好的数据可用性保证。

pg auto failover 文档可在 https://pg-auto-failover.readthedocs.io/ 上在线获取，并包括一个 完全详细的教程，以开始使用 Azure VM。

Pg Chameleon 是一个用 python 3.3+ 开发的 MySQL 到 PostgreSQL 复制系统。该系统可以实时将数据更改从 MySQL 复制到 PostgreSQL。

库 python-mysql-replication 从 mysql 复制协议收集数据更改，并将 PostgreSQL 用作中继日志和副本目标。

主页

Pypi 软件包

Github 页面

Pgpool-II 是一个用于 PostgreSQL 7.4 或更高版本的同步复制系统。它提供了使用 PostgreSQL 构建高性能/高可用性集群的所有所需功能，包括连接池和负载平衡。

Pgpool 还可以与其他复制系统（例如 Slony-I）集成。

Slony-I 是一个“主到多个从”复制系统，支持级联（例如 - 一个节点可以馈送另一个节点，而该节点又馈送另一个节点...）和故障转移。

Slony-I 的总体发展方向是，它是一个主从复制系统，包含将大型数据库复制到数量有限的从系统所需的所有特性和功能。

Slony-I 是一个为数据中心和备份站点设计的系统，其正常运行模式是所有节点都可用。

SPQR 是一个查询路由器，用于通过分片横向扩展 PostgreSQL。

主要特性

• 分片。如果可能，路由器会从事务的第一个语句确定一个分片，并保持客户端绑定到该分片，直到事务结束。但是您可以在注释请求中显式指定分片或分片键。
• 事务和会话池。就像您最喜欢的连接池 (Odyssey 或 PgBouncer) 一样。
• 用于容错的多个路由器。路由器仅出于缓存目的存储分片规则。有关整个安装的信息存储在 QDB 服务内部，因此同时运行的路由器数量不受限制。
• 流动数据迁移。分片之间的数据迁移旨在按比例平衡各个分片的工作负载。主要思想是尽量减少这些迁移期间的任何锁定影响，这是通过减少传输的数据范围的大小来实现的。
• 有限的跨分片查询。SPQR 路由器支持有限的跨分片查询子集。这是通过尽力而为的逻辑以非破坏性和非一致的方式实现的，主要用于测试目的。请不要在您的生产环境中使用此功能，跨分片快照将是不一致的。
• 多个服务器和故障转移。在路由器配置中，可以为一个分片指定多个服务器。然后，路由器将在副本之间分配只读查询。但是，除了自动路由之外，您还可以选择通过在查询中使用 target-session-attr 参数来显式定义特定查询的目标。
• 查询执行的开销较小。请参阅此处和此处的基准测试。

TCapture 是一个基于“捕获和应用”异步复制引擎的双向多主复制服务器

实际的 TCapture 引擎是一个 Java 应用程序，它作为“PostgreSQL”之外的单独程序运行，必须显式启动。当 TCapture 运行时，它将扫描所有主数据库的事务日志，并拾取必须复制的事务。已拾取的事务存储在“存储数据库”中，“存储数据库”是 TCapture 独占使用的 “PostgreSQL” 用户数据库。在存储数据库中，事务会“复制”到所有已订阅该事务的存储数据库。然后，将事务应用于复制数据库

TCapture 的吸引力之一在于它非常容易设置和配置：从头开始，您可以在 30 分钟内部署一个可工作的复制系统。设置过程在《TCapture 指南》中进行了描述。与复制一样，在开始之前，请确保您清楚地了解要实现的复制逻辑。

主要特性

• 事务性。 SQL 以事务方式捕获，可以与周围的业务逻辑耦合。
• 高效。它从预写日志 (WAL) 中捕获事务以进行复制，而不是使用触发器，从而消除了主数据库的开销并显着降低了延迟
• 灵活。对生产者或消费者的数量没有限制，但复杂性会增加
• 可靠。事务存储在“PostgreSQL”数据库中 – 这增加了预写日志记录和崩溃恢复的好处。
• 透明。对已在该数据库上运行的应用程序没有影响，因为引擎和“存储数据库”都可以与生产数据库分开运行。
• 易于使用。设置和配置简单，是不同“PostgreSQL”版本之间进行数据复制的有效工具
• 开源。没有许可费，但偶尔您需要自己动手