Shared disk failover avoids synchronization overhead by
having only one copy of the database. It uses a single disk
array that is shared by multiple servers. If the main
database server fails, the standby server is able to mount
and start the database as though it were recovering from a
database crash. This allows rapid failover with no data
loss.

Shared hardware functionality is common in network
storage devices. Using a network file system is also
possible, though care must be taken that the file system
has full POSIX behavior
(see Section
17.2.2). One significant limitation of this method is
that if the shared disk array fails or becomes corrupt, the
primary and standby servers are both nonfunctional. Another
issue is that the standby server should never access the
shared storage while the primary server is running.

File System (Block-Device) Replication

A modified version of shared hardware functionality is
file system replication, where all changes to a file system
are mirrored to a file system residing on another computer.
The only restriction is that the mirroring must be done in
a way that ensures the standby server has a consistent copy
of the file system — specifically, writes to the standby
must be done in the same order as those on the master.
DRBD is a popular file
system replication solution for Linux.

Warm and Hot Standby Using Point-In-Time Recovery
(PITR)

Warm and hot standby servers can be kept current by
reading a stream of write-ahead log (WAL) records. If the main server fails,
the standby contains almost all of the data of the main
server, and can be quickly made the new master database
server. This is asynchronous and can only be done for the
entire database server.

A PITR standby server can be implemented using
file-based log shipping (Section 25.2) or streaming
replication (see Section
25.2.5), or a combination of both. For information on
hot standby, see Section
25.5.

Trigger-Based Master-Standby Replication

A master-standby replication setup sends all data
modification queries to the master server. The master
server asynchronously sends data changes to the standby
server. The standby can answer read-only queries while the
master server is running. The standby server is ideal for
data warehouse queries.

Slony-I is an example
of this type of replication, with per-table granularity,
and support for multiple standby servers. Because it
updates the standby server asynchronously (in batches),
there is possible data loss during fail over.

Statement-Based Replication Middleware

With statement-based replication middleware, a program
intercepts every SQL query and sends it to one or all
servers. Each server operates independently. Read-write
queries are sent to all servers, while read-only queries
can be sent to just one server, allowing the read workload
to be distributed.

If queries are simply broadcast unmodified, functions
like random(), CURRENT_TIMESTAMP, and sequences can have
different values on different servers. This is because each
server operates independently, and because SQL queries are
broadcast (and not actual modified rows). If this is
unacceptable, either the middleware or the application must
query such values from a single server and then use those
values in write queries. Another option is to use this
replication option with a traditional master-standby setup,
i.e. data modification queries are sent only to the master
and are propagated to the standby servers via
master-standby replication, not by the replication
middleware. Care must also be taken that all transactions
either commit or abort on all servers, perhaps using
two-phase commit (PREPARE TRANSACTION and
COMMIT PREPARED.
Pgpool-II and Sequoia are examples of this type of
replication.

Asynchronous Multimaster Replication

For servers that are not regularly connected, like
laptops or remote servers, keeping data consistent among
servers is a challenge. Using asynchronous multimaster
replication, each server works independently, and
periodically communicates with the other servers to
identify conflicting transactions. The conflicts can be
resolved by users or conflict resolution rules. Bucardo is
an example of this type of replication.

Synchronous Multimaster Replication

In synchronous multimaster replication, each server can
accept write requests, and modified data is transmitted
from the original server to every other server before each
transaction commits. Heavy write activity can cause
excessive locking, leading to poor performance. In fact,
write performance is often worse than that of a single
server. Read requests can be sent to any server. Some
implementations use shared disk to reduce the communication
overhead. Synchronous multimaster replication is best for
mostly read workloads, though its big advantage is that any
server can accept write requests — there is no need to
partition workloads between master and standby servers, and
because the data changes are sent from one server to
another, there is no problem with non-deterministic
functions like random().

PostgreSQL does not
offer this type of replication, though PostgreSQL two-phase commit (PREPARE TRANSACTION and
COMMIT PREPARED) can
be used to implement this in application code or
middleware.

Commercial Solutions

Because PostgreSQL is
open source and easily extended, a number of companies have
taken PostgreSQL and
created commercial closed-source solutions with unique
failover, replication, and load balancing capabilities.

Table
25-1 summarizes the capabilities of the various solutions
listed above.

Data partitioning splits tables into data sets. Each set
can be modified by only one server. For example, data can
be partitioned by offices, e.g., London and Paris, with a
server in each office. If queries combining London and
Paris data are necessary, an application can query both
servers, or master/standby replication can be used to keep
a read-only copy of the other office's data on each
server.

Multiple-Server Parallel Query Execution

Many of the above solutions allow multiple servers to
handle multiple queries, but none allow a single query to
use multiple servers to complete faster. This solution
allows multiple servers to work concurrently on a single
query. It is usually accomplished by splitting the data
among servers and having each server execute its part of
the query and return results to a central server where they
are combined and returned to the user. Pgpool-II has this capability. Also,
this can be implemented using the PL/Proxy tool set.

Submit correction

If you see anything in the documentation that is not correct, does not match
your experience with the particular feature or requires further clarification,
please use
this form
to report a documentation issue.