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 bc09f40c584d65045c061ce84eb02ad6b8ccb2f0..9e2adbaab2ce339daacbff9365446c7841080c64 100644 (file)
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  High Availability and Load Balancing
@@ -133,11 +133,11 @@ protocol to make nodes agree on a serializable transactional order.
  
 
  
-  Master/Slave Replication
+  Master-Slave Replication
   
 
    
-    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.
  
 
  
-  Multi-Master Replication
+  Synchonous Multi-Master Replication
   
 
    
-    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 — 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
-    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
+    — 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 random().
    
 
    
@@ -216,7 +216,7 @@ protocol to make nodes agree on a serializable transactional order.
  
 
  
-  Multi-Master With Conflict Resolution
+  Asynchronous Multi-Master Replication