不同解决方案的比较

共享磁盘故障转移

共享磁盘故障转移通过仅拥有一个数据库副本来避免同步开销。它使用由多台服务器共享的单个磁盘阵列。如果主数据库服务器发生故障，备用服务器能够挂载并启动数据库，就像从数据库崩溃中恢复一样。这允许快速故障转移而不会丢失数据。

共享硬件功能在网络存储设备中很常见。也可以使用网络文件系统，但必须注意文件系统是否具有完整的POSIX行为（请参见第 18.2.2 节）。此方法的一个重大限制是，如果共享磁盘阵列发生故障或损坏，主服务器和备用服务器都将无法运行。另一个问题是，在主服务器运行时，备用服务器永远不应访问共享存储。

文件系统（块设备）复制

共享硬件功能的一个修改版本是文件系统复制，其中对文件系统的所有更改都会镜像到驻留在另一台计算机上的文件系统。唯一的限制是镜像必须以确保备用服务器具有文件系统的一致副本的方式进行 — 具体而言，对备用服务器的写入必须按照与主服务器相同的顺序进行。DRBD是一种流行的 Linux 文件系统复制解决方案。

事务日志传送

通过读取预写日志 ( WAL ) 记录流，温备用服务器和热备用服务器可以保持最新状态。如果主服务器发生故障，备用服务器将包含主服务器的几乎所有数据，并可以快速成为新的主数据库服务器。这可以是同步的，也可以是异步的，并且只能针对整个数据库服务器执行。

备用服务器可以使用基于文件的日志传送（第 26.2 节）或流复制（参见第 26.2.5 节）或两者结合来实现。有关热备用的信息，请参见第 26.5 节。

基于触发器的主备复制

主备复制设置将所有数据修改查询发送到主服务器。主服务器异步将数据更改发送到备用服务器。备用服务器可以在主服务器运行时回答只读查询。备用服务器是数据仓库查询的理想选择。

Slony-I是此类复制的一个示例，具有表级粒度，并支持多个备用服务器。由于它以异步方式（批量）更新备用服务器，因此在故障转移期间可能会丢失数据。

基于语句的复制中间件

使用基于语句的复制中间件，程序会拦截每个 SQL 查询并将其发送到一台或所有服务器。每台服务器独立运行。读写查询必须发送到所有服务器，以便每台服务器都能收到任何更改。但只读查询可以只发送到一台服务器，从而允许读取工作负载在它们之间分配。

如果查询只是未经修改地广播，那么诸如random()、CURRENT_TIMESTAMP和序列之类的函数在不同的服务器上可能会有不同的值。这是因为每个服务器都独立运行，并且 SQL 查询是广播的（而不是实际修改的行）。如果这是不可接受的，那么中间件或应用程序必须从单个服务器查询这些值，然后在写入查询中使用这些值。另一种选择是将此复制选项与传统的主备设置一起使用，即，数据修改查询仅发送给主服务器并通过主备复制传播到备用服务器，而不是通过复制中间件。还必须注意所有事务在所有服务器上提交或中止，也许使用两阶段提交（PREPARE TRANSACTION和COMMIT PREPARED）。Pgpool -II和Continuent Tungsten是此类复制的示例。

异步多主复制

对于不经常连接或通信链路较慢的服务器（如笔记本电脑或远程服务器），保持服务器之间的数据一致是一项挑战。使用异步多主复制，每台服务器独立工作，并定期与其他服务器通信以识别冲突的事务。冲突可以由用户或冲突解决规则解决。Bucardo 就是这种复制类型的一个例子。

同步多主复制

在同步多主复制中，每台服务器都可以接受写入请求，并且修改后的数据在每次事务提交之前都会从原始服务器传输到其他每台服务器。大量的写入活动可能会导致过多的锁定和提交延迟，从而导致性能不佳。读取请求可以发送到任何服务器。一些实现使用共享磁盘来减少通信开销。同步多主复制最适合大多数读取工作负载，但它的一大优势是任何服务器都可以接受写入请求 — 无需在主服务器和备用服务器之间划分工作负载，并且由于数据更改是从一台服务器发送到另一台服务器的，因此不会出现非确定性函数的问题random()。

 

PostgreSQL不提供这种类型的复制，尽管PostgreSQL两阶段提交（PREPARE TRANSACTION和COMMIT PREPARED）可用于在应用程序代码或中间件中实现此功能。

商业解决方案

由于PostgreSQL是开源的并且易于扩展，许多公司都采用PostgreSQL并创建了具有独特故障转移、复制和负载平衡功能的商业闭源解决方案。

高可用性、负载平衡和复制功能矩阵

Feature	Shared Disk Failover	File System Replication	Transaction Log Shipping	Trigger-Based Master-Standby Replication	Statement-Based Replication Middleware	Asynchronous Multimaster Replication	Synchronous Multimaster Replication
Most Common Implementation	NAS	DRBD	Streaming Repl.	Slony	pgpool-II	Bucardo
Communication Method	shared disk	disk blocks	WAL	table rows	SQL	table rows	table rows and row locks
No special hardware required		•	•	•	•	•	•
Allows multiple master servers					•	•	•
No master server overhead	•		•		•
No waiting for multiple servers	•		with sync off	•		•
Master failure will never lose data	•	•	with sync on		•		•
Standby accept read-only queries			with hot	•	•	•	•
Per-table granularity				•		•	•
No conflict resolution necessary	•	•	•	•	•		•