|
|
|
|
@ -1,4 +1,4 @@ |
|
|
|
|
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.18 2007/11/08 19:16:30 momjian Exp $ --> |
|
|
|
|
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.19 2007/11/08 19:18:23 momjian Exp $ --> |
|
|
|
|
|
|
|
|
|
<chapter id="high-availability"> |
|
|
|
|
<title>High Availability, Load Balancing, and Replication</title> |
|
|
|
|
@ -79,45 +79,45 @@ |
|
|
|
|
|
|
|
|
|
<variablelist> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Shared Disk Failover</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
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 was recovering from |
|
|
|
|
a database crash. This allows rapid failover with no data loss. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
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 <xref |
|
|
|
|
linkend="creating-cluster-nfs">). 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. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>File System Replication</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
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. |
|
|
|
|
</para> |
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Shared Disk Failover</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
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 was recovering from |
|
|
|
|
a database crash. This allows rapid failover with no data loss. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
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 <xref |
|
|
|
|
linkend="creating-cluster-nfs">). 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. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>File System Replication</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
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. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<!-- |
|
|
|
|
https://forge.continuent.org/pipermail/sequoia/2006-November/004070.html |
|
|
|
|
@ -128,150 +128,150 @@ only committed once to disk and there is a distributed locking |
|
|
|
|
protocol to make nodes agree on a serializable transactional order. |
|
|
|
|
--> |
|
|
|
|
|
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Warm Standby Using Point-In-Time Recovery (<acronym>PITR</>)</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
A warm standby server (see <xref linkend="warm-standby">) can |
|
|
|
|
be kept current by reading a stream of write-ahead log (WAL) |
|
|
|
|
records. If the main server fails, the warm 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. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Master-Slave Replication</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
A master-slave replication setup sends all data modification |
|
|
|
|
queries to the master server. The master server asynchronously |
|
|
|
|
sends data changes to the slave server. The slave can answer |
|
|
|
|
read-only queries while the master server is running. The |
|
|
|
|
slave server is ideal for data warehouse queries. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
Slony-I is an example of this type of replication, with per-table |
|
|
|
|
granularity, and support for multiple slaves. Because it |
|
|
|
|
updates the slave server asynchronously (in batches), there is |
|
|
|
|
possible data loss during fail over. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Statement-Based Replication Middleware</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
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. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
If queries are simply broadcast unmodified, functions like |
|
|
|
|
<function>random()</>, <function>CURRENT_TIMESTAMP</>, and |
|
|
|
|
sequences would 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. Also, care must be taken that all |
|
|
|
|
transactions either commit or abort on all servers, perhaps |
|
|
|
|
using two-phase commit (<xref linkend="sql-prepare-transaction" |
|
|
|
|
endterm="sql-prepare-transaction-title"> and <xref |
|
|
|
|
linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">. |
|
|
|
|
Pgpool and Sequoia are an example of this type of replication. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Asynchronous Multi-Master Replication</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
For servers that are not regularly connected, like laptops or |
|
|
|
|
remote servers, keeping data consistent among servers is a |
|
|
|
|
challenge. Using asynchronous multi-master 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. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Synchronous Multi-Master Replication</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
In synchronous multi-master 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 multi-master |
|
|
|
|
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 |
|
|
|
|
slave servers, and because the data changes are sent from one |
|
|
|
|
server to another, there is no problem with non-deterministic |
|
|
|
|
functions like <function>random()</>. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
<productname>PostgreSQL</> does not offer this type of replication, |
|
|
|
|
though <productname>PostgreSQL</> two-phase commit (<xref |
|
|
|
|
linkend="sql-prepare-transaction" |
|
|
|
|
endterm="sql-prepare-transaction-title"> and <xref |
|
|
|
|
linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">) |
|
|
|
|
can be used to implement this in application code or middleware. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Data Partitioning</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
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/slave replication can be used to keep a read-only copy |
|
|
|
|
of the other office's data on each server. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Commercial Solutions</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
Because <productname>PostgreSQL</> is open source and easily |
|
|
|
|
extended, a number of companies have taken <productname>PostgreSQL</> |
|
|
|
|
and created commercial closed-source solutions with unique |
|
|
|
|
failover, replication, and load balancing capabilities. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Warm Standby Using Point-In-Time Recovery (<acronym>PITR</>)</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
A warm standby server (see <xref linkend="warm-standby">) can |
|
|
|
|
be kept current by reading a stream of write-ahead log (WAL) |
|
|
|
|
records. If the main server fails, the warm 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. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Master-Slave Replication</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
A master-slave replication setup sends all data modification |
|
|
|
|
queries to the master server. The master server asynchronously |
|
|
|
|
sends data changes to the slave server. The slave can answer |
|
|
|
|
read-only queries while the master server is running. The |
|
|
|
|
slave server is ideal for data warehouse queries. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
Slony-I is an example of this type of replication, with per-table |
|
|
|
|
granularity, and support for multiple slaves. Because it |
|
|
|
|
updates the slave server asynchronously (in batches), there is |
|
|
|
|
possible data loss during fail over. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Statement-Based Replication Middleware</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
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. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
If queries are simply broadcast unmodified, functions like |
|
|
|
|
<function>random()</>, <function>CURRENT_TIMESTAMP</>, and |
|
|
|
|
sequences would 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. Also, care must be taken that all |
|
|
|
|
transactions either commit or abort on all servers, perhaps |
|
|
|
|
using two-phase commit (<xref linkend="sql-prepare-transaction" |
|
|
|
|
endterm="sql-prepare-transaction-title"> and <xref |
|
|
|
|
linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">. |
|
|
|
|
Pgpool and Sequoia are an example of this type of replication. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Asynchronous Multi-Master Replication</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
For servers that are not regularly connected, like laptops or |
|
|
|
|
remote servers, keeping data consistent among servers is a |
|
|
|
|
challenge. Using asynchronous multi-master 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. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Synchronous Multi-Master Replication</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
In synchronous multi-master 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 multi-master |
|
|
|
|
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 |
|
|
|
|
slave servers, and because the data changes are sent from one |
|
|
|
|
server to another, there is no problem with non-deterministic |
|
|
|
|
functions like <function>random()</>. |
|
|
|
|
</para> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
<productname>PostgreSQL</> does not offer this type of replication, |
|
|
|
|
though <productname>PostgreSQL</> two-phase commit (<xref |
|
|
|
|
linkend="sql-prepare-transaction" |
|
|
|
|
endterm="sql-prepare-transaction-title"> and <xref |
|
|
|
|
linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">) |
|
|
|
|
can be used to implement this in application code or middleware. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Data Partitioning</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
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/slave replication can be used to keep a read-only copy |
|
|
|
|
of the other office's data on each server. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
<varlistentry> |
|
|
|
|
<term>Commercial Solutions</term> |
|
|
|
|
<listitem> |
|
|
|
|
|
|
|
|
|
<para> |
|
|
|
|
Because <productname>PostgreSQL</> is open source and easily |
|
|
|
|
extended, a number of companies have taken <productname>PostgreSQL</> |
|
|
|
|
and created commercial closed-source solutions with unique |
|
|
|
|
failover, replication, and load balancing capabilities. |
|
|
|
|
</para> |
|
|
|
|
</listitem> |
|
|
|
|
</varlistentry> |
|
|
|
|
|
|
|
|
|
</variablelist> |
|
|
|
|
|
|
|
|
|
|
Bruce Momjian
18 years ago