Re: replication docs: split single vs. multi-master - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: replication docs: split single vs. multi-master
Date
Msg-id 200611162150.kAGLoVa06062@momjian.us
Whole thread Raw
In response to Re: replication docs: split single vs. multi-master  (Bruce Momjian <bruce@momjian.us>)
Responses Re: replication docs: split single vs. multi-master  (Markus Schiltknecht <markus@bluegap.ch>)
List pgsql-patches
Bruce Momjian wrote:
> I didn't mention distributed shared memory as a separate item because I
> felt it was an implementation detail of clustering, rather than
> something separate.  I kept two-phase in the cluster item for the same
> reason.
>
> Current version at:
>
>     http://momjian.us/main/writings/pgsql/sgml/failover.html

I am now attaching the additional text I added based on your comments.
I have also changed the markup so all the solutions appear on the same
web page.  I think seeing it all together might give us new ideas for
improvement.

--
  Bruce Momjian   bruce@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/failover.sgml
===================================================================
RCS file: /cvsroot/pgsql/doc/src/sgml/failover.sgml,v
retrieving revision 1.6
diff -c -c -r1.6 failover.sgml
*** doc/src/sgml/failover.sgml    15 Nov 2006 01:09:08 -0000    1.6
--- doc/src/sgml/failover.sgml    16 Nov 2006 17:12:49 -0000
***************
*** 33,38 ****
--- 33,50 ----
   </para>

   <para>
+   Some solutions deal with synchronization by allowing only one
+   server to modify the data.  Servers that can modify data are
+   called read/write or "master" server.  Servers with read-only
+   data are called backup or "slave" servers.  As you will see below,
+   these terms cover a variety of implementations.  Some servers
+   are masters of some data sets, and slave of others.  Some slaves
+   cannot be accessed until they are changed to master servers,
+   while other slaves can reply to read-only queries while they are
+   slaves.
+  </para>
+
+  <para>
    Some failover and load balancing solutions are synchronous, meaning that
    a data-modifying transaction is not considered committed until all
    servers have committed the transaction.  This guarantees that a failover
***************
*** 118,132 ****
    <title>Data Partitioning</title>

    <para>
!    Data partitioning splits tables into data sets.  Each set can only be
!    modified by one server.  For example, data can be partitioned by
!    offices, e.g. London and Paris.  While London and Paris servers have all
!    data records, only London can modify London records, and Paris can only
!    modify Paris records.
    </para>

    <para>
!    Such partitioning implements both failover and load balancing.  Failover
     is achieved because the data resides on both servers, and this is an
     ideal way to enable failover if the servers share a slow communication
     channel. Load balancing is possible because read requests can go to any
--- 130,149 ----
    <title>Data Partitioning</title>

    <para>
!    Data partitioning splits tables into data sets.  Each set can
!    be modified by only one server.  For example, data can be
!    partitioned by offices, e.g. London and Paris.  While London
!    and Paris servers have all data records, only London can modify
!    London records, and Paris can only modify Paris records.  This
!    is similar to section <xref
!    linkend="continuously-running-replication-server"> above, except
!    that instead of having a read/write server and a read-only server,
!    each server has a read/write data set and a read-only data
!    set.
    </para>

    <para>
!    Such partitioning provides both failover and load balancing.  Failover
     is achieved because the data resides on both servers, and this is an
     ideal way to enable failover if the servers share a slow communication
     channel. Load balancing is possible because read requests can go to any

pgsql-patches by date:

Previous
From: Markus Schiltknecht
Date:
Subject: Re: replication docs: split single vs. multi-master
Next
From: "Dwight Emmons"
Date:
Subject: Cast null to int4 upgrading from Version 7.2