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

table to docs.

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 974da2c80a01a86e043301bd891369506bd60906..6bb6046af367e4c3e6f09d360ce2d6f275519167 100644 (file)
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  High Availability, Load Balancing, and Replication
@@ -92,16 +92,23 @@
    
 
    
-    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 
+    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.
    
 
+  
+ 
+
+ 
+  File System Replication
+  
+
    
     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.
  
 
  
-  Warm Standby Using Point-In-Time Recovery
+  Warm Standby Using Point-In-Time Recovery (PITR)
   
 
    
@@ -190,6 +197,21 @@ protocol to make nodes agree on a serializable transactional order.
   
  
 
+ 
+  Asynchronous Multi-Master Replication
+  
+
+   
+    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.
+   
+  
+ 
+
  
   Synchronous Multi-Master Replication
   
@@ -222,21 +244,6 @@ protocol to make nodes agree on a serializable transactional order.
   
  
 
- 
-  Asynchronous Multi-Master Replication
-  
-
-   
-    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.
-   
-  
- 
-
  
   Data Partitioning
   
@@ -253,23 +260,6 @@ protocol to make nodes agree on a serializable transactional order.
   
  
 
- 
-  Multi-Server Parallel Query Execution
-  
-
-   
-    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.
-   
-  
- 
-
  
   Commercial Solutions
   
@@ -285,4 +275,139 @@ protocol to make nodes agree on a serializable transactional order.
 
  
 
+ 
+  The table below () summarizes
+  the capabilities of the various solutions listed above.
+ 
+
+ 
+  High Availability, Load Balancing, and Replication Feature Matrix
+  
+   
+    
+     Feature
+     Shared Disk Failover
+     File System Replication
+     Warm Standby Using PITR
+     Master-Slave Replication
+     Statement-Based Replication Middleware
+     Asynchronous Multi-Master Replication
+     Synchronous Multi-Master Replication
+     Data Partitioning
+    
+   
+
+   
+
+    
+     No special hardware required
+     
+     •
+     •
+     •
+     •
+     •
+     •
+     •
+    
+
+    
+     Allows multiple master servers
+     
+     
+     
+     
+     •
+     •
+     •
+     
+    
+
+    
+     No master server overhead
+     •
+     
+     •
+     
+     
+     
+     
+     
+    
+
+    
+     Master server never locks others
+     •
+     •
+     •
+     •
+     •
+     •
+     
+     •
+    
+
+    
+     Master failure will never lose data
+     •
+     •
+     
+     
+     •
+     
+     •
+     
+    
+
+    
+     Slaves accept read-only queries
+     
+     
+     
+     •
+     •
+     •
+     •
+     •
+    
+
+    
+     Per-table granularity
+     
+     
+     
+     •
+     
+     •
+     •
+     •
+    
+
+    
+     No conflict resolution necessary
+     •
+     •
+     •
+     •
+     
+     
+     •
+     •
+    
+
+   
+  
+ 
+
+ 
+  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.
+ 
+