From: Bruce Momjian <bruce@momjian.us>
Date: Wed, 22 Nov 2006 04:01:40 +0000 (+0000)
Subject: New async/sync multi-master headings for docs.
X-Git-Tag: REL8_2_RC1~35
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=8c556ce1c21c09a8d7f8e0a100cd00fd8faf437c;p=postgresql

New async/sync multi-master headings for docs.
---

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index bc09f40c58..9e2adbaab2 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.10 2006/11/22 04:00:19 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.11 2006/11/22 04:01:40 momjian Exp $ -->
 
 <chapter id="high-availability">
  <title>High Availability and Load Balancing</title>
@@ -133,11 +133,11 @@ protocol to make nodes agree on a serializable transactional order.
  </varlistentry>
 
  <varlistentry>
-  <term>Master/Slave Replication</term>
+  <term>Master-Slave Replication</term>
   <listitem>
 
    <para>
-    A master/slave replication setup sends all data modification
+    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
@@ -184,24 +184,24 @@ protocol to make nodes agree on a serializable transactional order.
  </varlistentry>
 
  <varlistentry>
-  <term>Multi-Master Replication</term>
+  <term>Synchonous Multi-Master Replication</term>
   <listitem>
 
    <para>
-    In 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 cluster-wide shared memory
-    or shared disk to reduce the communication overhead.  Clustering
-    is best for mostly read workloads, though its big advantage is
-    that any server can accept write requests &mdash; 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()</>.
+    In synchonous 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 cluster-wide
+    shared memory or shared disk to reduce the communication
+    overhead.  Clustering is best for mostly read workloads, though
+    its big advantage is that any server can accept write requests
+    &mdash; 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>
@@ -216,7 +216,7 @@ protocol to make nodes agree on a serializable transactional order.
  </varlistentry>
 
  <varlistentry>
-  <term>Multi-Master With Conflict Resolution</term>
+  <term>Asynchronous Multi-Master Replication</term>
   <listitem>
 
    <para>