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

Markus Schiltknecht wrote:
> Hi,
>
> as promised on -docs, here comes my proposal on how to improve the
> replication documentation. The patches are split as follows and have to
> be applied in order:
>
> replication_doku_1.diff:
>
>    Smallest possible one-word change to warm-up...

Done.

>
>
> replication_doku_2.diff:
>
>    Moves down "Clustering For Parallel Query Execution", because
>    it's not a replication type, but a feature, see explanation below.
>

Actually the patch moves down data paritioning.  I am confused.

> replication_doku_3.diff:
>
>    This is the most important part, splitting all replication types
>    into single- and multi-master replication.  I'm new to SGML, so
>    please bear with me if this is not the right way to do it...
>
>    "Shared-Disk-Failover" does IMO not fall into a replication category.
>    Should we mention there, that 'sharing' a disk using NFS or some
>    such is not recommended? (And more importantly, does not work as
>    a multi-master replication solution)
>
>    I've added a general paragraph describing Single-Master Replication.
>    I'm stating that 'Single-Master Replication is always asynchronous'.
>    Can anybody think of a counter example? Or a use case for sync
>    Single-Master Replication? The argument to put down is: if you go
>    sync, why don't you do Multi-Master right away?
>
>    Most of the "Clustering for Load Balancing" text applies to all
>    synchronous, Multi-Master Replication algorithms, even to
>    "Query Broadcasting". Thus it became the general description
>    of Multi-Master Replication. The section "Clustering for
>    Load Balancing" has been removed.

I thought a long time about this.  I have always liked splitting the
solutions up into single and multi-master, but in doing this
documentation section, I realized that the split isn't all that helpful,
and can be confusing.  For example, Slony is clearly single-master, but
what about data partitioning?  That is multi-master, in that there is
more than one master, but only one master per data set.  And for
multi-master, Oracle RAC is clearly multi master, and I can see pgpool
as multi-master, or as several single-master systems, in that they
operate independently.  After much thought, it seems that putting things
into single/multi-master categories just adds more confusion, because
several solutions just aren't clear, or fall into neither, e.g. Shared
Disk Failover.  Another issue is that you mentioned heavly locking for
multi-master, when in fact pgpool doesn't do any special inter-server
locking, so it just doesn't apply.

In summary, it just seemed clearer to talk about each item and how it
works, rather than try to categorize them.  The categorization just
seems to do more harm than good.

Of course, I might be totally wrong, and am still looking for feedback,
but these are my current thoughts.  Feedback?

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

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

  + If your life is a hard drive, Christ can be your backup. +