软件目录 - 集群/复制

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

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

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

它定义了一个名为 Cluster 的新 Kubernetes 资源，代表一个由单个主节点和可选数量的副本组成的 PostgreSQL 集群，这些副本共存于选定的 Kubernetes 命名空间中，用于高可用性和读查询卸载。

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

CloudNativePG 最初由 EDB 构建，然后根据 Apache 许可证 2.0 开源发布，并于 2022 年 4 月提交给 CNCF Sandbox。 源代码存储库位于 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 实例集群。它简化了使用 PostgreSql 的过程，考虑到使用 Kubernetes 管理有状态集生命周期和数据复制的复杂性。

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 机械特别兴趣小组 (SIG) 维护。

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

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

该框架的签名功能是它允许您使用带有参数的自由格式 SQL 查询来细分中心服务器数据。每个本地数据库都可以与中心数据库共享共享数据和私有数据。

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

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

pg_auto_failover 支持多种 Postgres 架构，并为您的 Postgres 服务实现了安全的自动故障转移。您可以从只有两个数据节点开始，这两个节点将由监视器分配主节点和次节点角色。从 pg_auto_failover 版本 1.4 开始，可以实现具有任意数量 Postgres 节点的生产架构，以获得更好的数据可用性保证。

pg 自动故障转移文档在线地址为 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”版本之间数据复制的有效工具。
• 开源。没有许可费用，但有时您需要自己动手。