Add "High Availability, Load Balancing, and Replication Feature Matrix"

table to docs.
This commit is contained in:
Bruce Momjian 2007-11-08 19:16:30 +00:00
parent 5db1c58a1a
commit 621e14dcb2

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.17 2007/11/04 19:23:24 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.18 2007/11/08 19:16:30 momjian Exp $ -->
<chapter id="high-availability">
<title>High Availability, Load Balancing, and Replication</title>
@ -92,16 +92,23 @@
</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.
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
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
@ -125,7 +132,7 @@ protocol to make nodes agree on a serializable transactional order.
</varlistentry>
<varlistentry>
<term>Warm Standby Using Point-In-Time Recovery</term>
<term>Warm Standby Using Point-In-Time Recovery (<acronym>PITR</>)</term>
<listitem>
<para>
@ -190,6 +197,21 @@ protocol to make nodes agree on a serializable transactional order.
</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>
@ -222,21 +244,6 @@ protocol to make nodes agree on a serializable transactional order.
</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>Data Partitioning</term>
<listitem>
@ -253,23 +260,6 @@ protocol to make nodes agree on a serializable transactional order.
</listitem>
</varlistentry>
<varlistentry>
<term>Multi-Server Parallel Query Execution</term>
<listitem>
<para>
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. This 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.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Commercial Solutions</term>
<listitem>
@ -285,4 +275,139 @@ protocol to make nodes agree on a serializable transactional order.
</variablelist>
<para>
The table below (<xref linkend="high-availability-matrix">) summarizes
the capabilities of the various solutions listed above.
</para>
<table id="high-availability-matrix">
<title>High Availability, Load Balancing, and Replication Feature Matrix</title>
<tgroup cols="9">
<thead>
<row>
<entry>Feature</entry>
<entry>Shared Disk Failover</entry>
<entry>File System Replication</entry>
<entry>Warm Standby Using PITR</entry>
<entry>Master-Slave Replication</entry>
<entry>Statement-Based Replication Middleware</entry>
<entry>Asynchronous Multi-Master Replication</entry>
<entry>Synchronous Multi-Master Replication</entry>
<entry>Data Partitioning</entry>
</row>
</thead>
<tbody>
<row>
<entry>No special hardware required</entry>
<entry align="center"></entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
</row>
<row>
<entry>Allows multiple master servers</entry>
<entry align="center"></entry>
<entry align="center"></entry>
<entry align="center"></entry>
<entry align="center"></entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center"></entry>
</row>
<row>
<entry>No master server overhead</entry>
<entry align="center">&bull;</entry>
<entry align="center"></entry>
<entry align="center">&bull;</entry>
<entry align="center"></entry>
<entry align="center"></entry>
<entry align="center"></entry>
<entry align="center"></entry>
<entry align="center"></entry>
</row>
<row>
<entry>Master server never locks others</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center"></entry>
<entry align="center">&bull;</entry>
</row>
<row>
<entry>Master failure will never lose data</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center"></entry>
<entry align="center"></entry>
<entry align="center">&bull;</entry>
<entry align="center"></entry>
<entry align="center">&bull;</entry>
<entry align="center"></entry>
</row>
<row>
<entry>Slaves accept read-only queries</entry>
<entry align="center"></entry>
<entry align="center"></entry>
<entry align="center"></entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
</row>
<row>
<entry>Per-table granularity</entry>
<entry align="center"></entry>
<entry align="center"></entry>
<entry align="center"></entry>
<entry align="center">&bull;</entry>
<entry align="center"></entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
</row>
<row>
<entry>No conflict resolution necessary</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
<entry align="center"></entry>
<entry align="center"></entry>
<entry align="center">&bull;</entry>
<entry align="center">&bull;</entry>
</row>
</tbody>
</tgroup>
</table>
<para>
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. Multi-server parallel query execution allows multiple
servers to work concurrently on a single query. This 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.
</para>
</chapter>