*** doc/src/sgml/failover.sgml	2006-11-15 11:11:12.000000000 +0100
--- doc/src/sgml/failover.sgml	2006-11-15 11:05:58.000000000 +0100
***************
*** 141,181 ****

    <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
!    program intercept every SQL query and send it to all servers.
!    This is unique because most replication solutions have the write
!    server propagate its changes to the other servers.  With query
!    broadcasting, each server operates independently.  Read-only
!    queries can be sent to a single server because there is no need
!    for all servers to process it.
    </para>

    <para>
!    One limitation of this solution is that functions like
!    <function>random()</>, <function>CURRENT_TIMESTAMP</>, and
!    sequences can have different values on different servers.  This
!    is because each server operates independently, and because SQL
!    queries are broadcast (and not actual modified rows).  If this
!    is unacceptable, applications must query such values from a
!    single server and then use those values in write queries.  Also,
!    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>

--- 141,215 ----

    <title>Multi-Master Replication</title>

!    <para>
!     With Multi-Master Replication, each server can accept write requests,
!     and modified data is transmitted to all servers.  Heavy write activity
!     causes network traffic and excessive locking, leading to poor performance
!     especially for synchronous Multi-Master Replication.  The write
!     performance can therefore be worse than that of a single server. Thus
!     Multi-Master Replication works 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>
!     Because every server has a consistent copy (replica) of the data, read
!     requests can be sent to any server.  In asynchronous Multi-Master
!     Replication the servers replica diverge until re-synchronized.
!     Likewise, conflicts in committed transactions can only be detected during
!     re-synchronization.  So either the application has to ensure not to send
!     conflicting transactions or the conflicts have to be resolved somehow
!     during re-synchronization of the servers.
!    </para>

   <sect2 id="query-broadcast">
    <title>Query Broadcasting</title>

    <para>
!    Query broadcasting is often accomplished by having a program intercept
!    data-modifying SQL queries and send them to all servers.  With query
!    broadcasting, each server operates independently, thus every
!    data-modifying transaction has to be processed on every server.  Pgpool
!    is an example of this type of replication.
!   </para>
! 
!   <para>
!    One challenge in implementing this solution is that functions like
!    <function>random()</> or <function>CURRENT_TIMESTAMP</> can return
!    different values on different servers.  So if only plain SQL gets
!    transmitted, the application has to cope with these differences.
!    Some solutions try to correctly handle these situations by executing
!    the non-deterministic functions on only one server and propagating
!    the result together with the rest of the SQL to the others.
!   </para>
!  </sect2>
! 
!  <sect2 id="two-phase-commit-replication">
!   <title>Using Two Phase Commit</title>
! 
!   <para>
!    <productname>PostgreSQL</productname> offers two-phase commit
!    (<xref linkend="sql-prepare-transaction"
!    endterm="sql-prepare-transaction-title"> and <xref
!    linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">
!    which can be used to implement synchronous Multi-Master replication
!    in application code or middleware.  As with Query Broadcasting, care
!    has to be taken with non-deterministic functions.
    </para>
+  </sect2>
+ 
+  <sect2 id="distributed-shared-memory-replication">
+   <title>Using Distributed Shared Memory</title>

    <para>
!    A different approach is to use Distributed Shared Memory to propagate
!    the modified data and all the locks of data-modifying transactions.
!    This can be done on the level of the operating system, i.e. with
!    OpenMosix or within the database itself.  However, in both methods
!    generate a lot of network traffic and do not scale very well for that
!    reason.  Pgpool-II is an effort to implement Distributed Shared Memory
!    Replication for PostgreSQL.
    </para>
   </sect2>