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 e3368042f02f305ad377735f74149d65efb2aa18..3ba8e838d0a91986cd7ccfeac4ffe73aa8373ce5 100644 (file)
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -184,22 +184,22 @@ protocol to make nodes agree on a serializable transactional order.
  </varlistentry>
 
  <varlistentry>
-  <term>Multi-Master Clustering</term>
+  <term>Multi-Master Replication</term>
   <listitem>
 
    <para>
-    In clustering, 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,
+    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()</>.
    </para>
@@ -246,7 +246,7 @@ protocol to make nodes agree on a serializable transactional order.
  </varlistentry>
 
  <varlistentry>
-  <term>Clustering For Parallel Query Execution</term>
+  <term>Multi-Server Parallel Query Execution</term>
   <listitem>
 
    <para>