Use more standard terms for replication, ideas from Markus Schiltknecht.

doc/src/sgml/failover.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/failover.sgml,v 1.9 2006/11/16 21:45:25 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/failover.sgml,v 1.10 2006/11/17 04:52:46 momjian Exp $ -->
 
 <chapter id="failover">
  <title>Failover, Replication, Load Balancing, and Clustering Options</title>
@@ -9,7 +9,7 @@
  <indexterm><primary>clustering</></>
 
  <para>
-  Database servers can work together to allow a backup server to
+  Database servers can work together to allow a second server to
   quickly take over if the primary server fails (failover), or to
   allow several computers to serve the same data (load balancing).
   Ideally, database servers could work together seamlessly.  Web
@@ -35,13 +35,10 @@
  <para>
   Some solutions deal with synchronization by allowing only one
   server to modify the data.  Servers that can modify data are
-  called read/write or "master" server.  Servers with read-only
+  called read/write or "master" servers.  Servers that can reply
-  data are called backup or "slave" servers.  As you will see below,
+  to read-only queries are called "slave" servers.  Servers that
-  these terms cover a variety of implementations.  Some servers
+  cannot be accessed until they are changed to master servers are
-  are masters of some data sets, and slave of others.  Some slaves
+  called "standby" servers.
-  cannot be accessed until they are changed to master servers,
-  while other slaves can reply to read-only queries while they are
-  slaves.
  </para>
 
  <para>
@@ -85,16 +82,20 @@
    <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 backup server
+    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.  One
+    Shared hardware functionality is common in network storage
-    significant limitation of this method is that if the shared disk array
+    devices.  Using a network file system is also possible, though
-    fails or becomes corrupt, the primary and backup servers are both
+    care must be taken that the file system has full POSIX behavior.
-    nonfunctional.
+    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>
@@ -115,21 +116,22 @@
  </varlistentry>
 
  <varlistentry>
-  <term>Continuously Running Replication Server</term>
+  <term>Master/Slave Replication</term>
   <listitem>
 
    <para>
-    A continuously running replication server allows the backup server to
+    A master/slave replication setup sends all data modification
-    answer read-only queries while the master server is running.  It
+    queries to the master server.  The master server asynchonously
-    receives a continuous stream of write activity from the master server.
+    sends data changes to the slave server.  The slave can answer
-    Because the backup server can be used for read-only database requests,
+    read-only queries while the master server is running.  The
-    it is ideal for data warehouse queries.
+    slave server is ideal for data warehouse queries.
    </para>
 
    <para>
     Slony-I is an example of this type of replication, with per-table
-    granularity.  It updates the backup server in batches, so the replication
+    granularity, and support for multiple slaves.  Because it
-    is asynchronous and might lose data during a fail over.
+    updates the slave server asynchronously (in batches), there is
+    possible data loss during fail over.
    </para>
   </listitem>
  </varlistentry>
@@ -144,10 +146,10 @@
     partitioned by offices, e.g. London and Paris.  While London
     and Paris servers have all data records, only London can modify
     London records, and Paris can only modify Paris records.  This
-    is similar to the "Continuously Running Replication Server"
+    is similar to the "Master/Slave Replication" item above, except
-    item above, except that instead of having a read/write server
+    that instead of having a read/write server and a read-only
-    and a read-only server, each server has a read/write data set
+    server, each server has a read/write data set and a read-only
-    and a read-only data set.
+    data set.
    </para>
 
    <para>
@@ -161,7 +163,7 @@
     the London/Paris example above.
    </para>
 
-    <para>
+   <para>
     Data partitioning is usually handled by application code, though rules
     and triggers can be used to keep the read-only data sets current.  Slony-I
     can also be used in such a setup.  While Slony-I replicates only entire
@@ -172,17 +174,15 @@
  </varlistentry>
 
  <varlistentry>
-  <term>Query Broadcast Load Balancing</term>
+  <term>Multi-Master Replication Using Query Broadcasting</term>
   <listitem>
 
    <para>
-    Query broadcast load balancing is accomplished by having a
+    One way to do multi-master replication is by having a program
-    program intercept every SQL query and send it to all servers.
+    intercept every SQL query and send it to all servers.  Each
-    This is unique because most replication solutions have the write
+    server operates independently.  Read-only queries can be sent
-    server propagate its changes to the other servers.  With query
+    to a single server because there is no need for all servers to
-    broadcasting, each server operates independently.  Read-only
+    process it.
-    queries can be sent to a single server because there is no need
-    for all servers to process it.
    </para>
 
    <para>
@@ -204,19 +204,22 @@
  </varlistentry>
 
  <varlistentry>
-  <term>Clustering For Load Balancing</term>
+  <term>Multi-Master Replication Using Custering</term>
   <listitem>
 
-    <para>
+   <para>
-    In clustering, each server can accept write requests, and modified
+    In clustering, each server can accept write requests, and
-    data is transmitted from the original server to every other
+    modified data is transmitted from the original server to every
-    server before each transaction commits.  Heavy write activity
+    other server before each transaction commits.  Heavy write
-    can cause excessive locking, leading to poor performance.  In
+    activity can cause excessive locking, leading to poor performance.
-    fact, write performance is often worse than that of a single
+    In fact, write performance is often worse than that of a single
     server.  Read requests can be sent to any server.  Clustering
-    is best for mostly read workloads, though its big advantage is
+    is best for mostly read workloads, though its big advantage
-    that any server can accept write requests &mdash; there is no need
+    is that any server can accept write requests &mdash; there is
-    to partition workloads between read/write and read-only servers.
+    no need to partition workloads between master and slave servers,
+    and because the changes are sent from one server to another,
+    there is not a problem with non-deterministic functions like
+    <function>random()</>.
    </para>
 
    <para>