*** doc/src/sgml/failover.sgml	2006-11-15 09:10:53.000000000 +0100
--- doc/src/sgml/failover.sgml	2006-11-15 11:11:12.000000000 +0100
***************
*** 83,89 ****
    </para>
   </sect1>
  
!  <sect1 id="warm-standby-using-point-in-time-recovery">
    <title>Warm Standby Using Point-In-Time Recovery</title>
  
    <para>
--- 83,107 ----
    </para>
   </sect1>
  
!  <sect1 id="single-master-replication">
!   <indexterm><primary>single-master</></>
! 
!   <title>Single-Master Replication</title>
! 
!    <para>
!     When using only one server to process data-modifying transactions we
!     speak of a master server and Single-Master Replication.  It is used
!     to allow one or more slave servers to stay current and therefore
!     provide a quick failover for high availability.
!    </para>
! 
!    <para>
!     Single-Master Replication is always asynchronous to allow the master
!     to process data-modifying transactions at full speed, but with the
!     downside of possible data loss during failover.
!    </para>
! 
!  <sect2 id="warm-standby-using-point-in-time-recovery">
    <title>Warm Standby Using Point-In-Time Recovery</title>
  
    <para>
***************
*** 94,102 ****
     made the new master database server.  This is asynchronous and
     can only be done for the entire database server.
    </para>
!  </sect1>
  
!  <sect1 id="continuously-running-replication-server">
    <title>Continuously Running Replication Server</title>
  
    <para>
--- 112,120 ----
     made the new master database server.  This is asynchronous and
     can only be done for the entire database server.
    </para>
!  </sect2>
  
!  <sect2 id="continuously-running-replication-server">
    <title>Continuously Running Replication Server</title>
  
    <para>
***************
*** 112,121 ****
     granularity.  It updates the backup server in batches, so the replication
     is asynchronous and might lose data during a fail over.
    </para>
   </sect1>
  
!  <sect1 id="query-broadcast-load-balancing">
!   <title>Query Broadcast Load Balancing</title>
  
    <para>
     Query broadcast load balancing is accomplished by having a
--- 130,160 ----
     granularity.  It updates the backup server in batches, so the replication
     is asynchronous and might lose data during a fail over.
    </para>
+  </sect2>
+ 
   </sect1>
  
! 
!  <sect1 id="Multi-Master Replication">
! 
!   <indexterm><primary>multi-master</></>
! 
!   <title>Multi-Master Replication</title>
! 
!   <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.  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 read/write and read-only servers.
!   </para>
! 
!  <sect2 id="query-broadcast">
!   <title>Query Broadcasting</title>
  
    <para>
     Query broadcast load balancing is accomplished by having a
***************
*** 138,170 ****
     care must be taken that all transactions either commit or abort
     on all servers  Pgpool is an example of this type of replication.
    </para>
!  </sect1>
! 
!  <sect1 id="clustering-for-load-balancing">
!   <title>Clustering For Load Balancing</title>
! 
!   <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.  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 read/write and read-only servers.
!   </para>
  
-   <para>
-    Clustering is implemented by <productname>Oracle</> in their
-    <productname><acronym>RAC</></> product.  <productname>PostgreSQL</>
-    does not offer this type of load balancing, though
-    <productname>PostgreSQL</> two-phase commit (<xref
-    linkend="sql-prepare-transaction"
-    endterm="sql-prepare-transaction-title"> and <xref
-    linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">)
-    can be used to implement this in application code or middleware.
-   </para>
   </sect1>
  
   <sect1 id="data-partitioning">
--- 177,184 ----
     care must be taken that all transactions either commit or abort
     on all servers  Pgpool is an example of this type of replication.
    </para>
!  </sect2>
  
   </sect1>
  
   <sect1 id="data-partitioning">