From: Bruce Momjian Date: Thu, 8 Nov 2007 19:16:30 +0000 (+0000) Subject: Add "High Availability, Load Balancing, and Replication Feature Matrix" X-Git-Tag: REL9_0_0~4650 X-Git-Url: http://git.osdn.net/view?a=commitdiff_plain;h=621e14dcb280be61d1a942ddb5e98dcc167b4813;p=pg-rex%2Fsyncrep.git 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 974da2c80a..6bb6046af3 100644 --- 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 ). 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) @@ -191,6 +198,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 @@ -223,21 +245,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 @@ -254,23 +261,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. + +