Rename replication section "High Availability and Load Balancing".

diff --git a/doc/src/sgml/filelist.sgml b/doc/src/sgml/filelist.sgml
index 945b08375fcb8a703cad5131e9aab603cb4fe8bd..fe1fdfd579433e1e8305525f445f6c0b5916be64 100644 (file)
--- a/doc/src/sgml/filelist.sgml
+++ b/doc/src/sgml/filelist.sgml
@@ -1,4 +1,4 @@
-
+
 
 
 
@@ -34,7 +34,7 @@
 
 
 
-failover      SYSTEM "failover.sgml">
+high-availability      SYSTEM "high-availability.sgml">
 
 
 

diff --git a/doc/src/sgml/failover.sgml b/doc/src/sgml/high-availability.sgml
similarity index 86%
rename from doc/src/sgml/failover.sgml
rename to doc/src/sgml/high-availability.sgml
index 29d770c73e1de7a6bdf87e8ab97c51ca61bbd3f4..56733e38e847fb10ecf7d3158edb2d25a21e9f33 100644 (file)
--- a/doc/src/sgml/failover.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,35 +1,38 @@
-
+
 
-failover">
- <span class="marked">Failover, Replication, Load Balancing, and Clustering Options</span>
+high-availability">
+ <span class="marked">High Availability and Load Balancing</span>
 
+ high availability
  failover
  replication
  load balancing
  clustering
+ data partitioning
 
  
   Database servers can work together to allow a second server to
-  quickly take over if the primary server fails (failover), or to
-  allow several computers to serve the same data (load balancing).
-  Ideally, database servers could work together seamlessly.  Web
-  servers serving static web pages can be combined quite easily by
-  merely load-balancing web requests to multiple machines.  In
-  fact, read-only database servers can be combined relatively easily
-  too.  Unfortunately, most database servers have a read/write mix
-  of requests, and read/write servers are much harder to combine.
-  This is because though read-only data needs to be placed on each
-  server only once, a write to any server has to be propagated to
-  all servers so that future read requests to those servers return
-  consistent results.
+  quickly take over quickly if the primary server fails (high
+  availability), or to allow several computers to serve the same
+  data (load balancing).  Ideally, database servers could work
+  together seamlessly.  Web servers serving static web pages can
+  be combined quite easily by merely load-balancing web requests
+  to multiple machines.  In fact, read-only database servers can
+  be combined relatively easily too.  Unfortunately, most database
+  servers have a read/write mix of requests, and read/write servers
+  are much harder to combine.  This is because though read-only
+  data needs to be placed on each server only once, a write to any
+  server has to be propagated to all servers so that future read
+  requests to those servers return consistent results.
  
 
  
-  This synchronization problem is the fundamental difficulty for servers
-  working together.  Because there is no single solution that eliminates
-  the impact of the sync problem for all use cases, there are multiple
-  solutions.  Each solution addresses this problem in a different way, and
-  minimizes its impact for a specific workload.
+  This synchronization problem is the fundamental difficulty for
+  servers working together.  Because there is no single solution
+  that eliminates the impact of the sync problem for all use cases,
+  there are multiple solutions.  Each solution addresses this
+  problem in a different way, and minimizes its impact for a specific
+  workload.
  
 
  

diff --git a/doc/src/sgml/postgres.sgml b/doc/src/sgml/postgres.sgml
index bba2bcd6019bc5a373325a5d0c3e83109b27828b..4f55c2dcacda7dbd4b3e8437934b700f30dac545 100644 (file)
--- a/doc/src/sgml/postgres.sgml
+++ b/doc/src/sgml/postgres.sgml
@@ -1,4 +1,4 @@
-
+
 
 
 
@@ -151,7 +151,7 @@
   &charset;
   &maintenance;
   &backup;
-  &failover;
+  &high-availability;
   &monitoring;
   &diskusage;
   &wal;