Re: On "multi-master"

Andrew Sullivan wrote:

>On Thu, Oct 13, 2005 at 10:46:29AM -0500, Scott Marlowe wrote:
>
>
>>choice in another.  So, multi-master replication isn't likely to become
>>a plug in module for postgresql any time soon.
>>
>>
>
>It's not even a thing, so it can't become a plug-in.
>
>
I was referring specifically to Multimaster Async Replication.

>Consider just two kinds of multi-master:
>
>1.    Oracle's RAC.  This is a shared-disk, engine-failover kind of
>multi-master.  It provides a certain amount of scaling, but nothing
>I've seen or heard suggests that the license cost couldn't just as
>easily and effectively be thrown at larger hardware for better
>scaling.  The really big reason to use RAC is five-nines situations:
>you're trying to make sure that even unlikely failures of your
>machines never cause the database to stop working (for suitably
>lawyer-understood values of "stop".  RAC remastering is not a
>zero-cost, nor even invisible, operation.  But from an application
>perspective, it can be made to look like "database is slow" as
>opposed to "database crashed").
>
>
So this is basically a multimaster synchronous replication solution
utilizing a shared disk architecture.  I generally agree with your
assessment that the license costs could be better spent on redundant
hardware and more scalable hardware.  Also if the shared disk fails, you
may lose everything after your last backup.

Now, what about PgPool as a multimaster sync replication solution?  Sure
it is statement level....  But is there any reason why you cannot have
multiple PgPool instances running against a number of DB servers?

>2.    Disconnected sales forces with local copies of some portion
>of the sales database.  This is completely distributed database use,
>with potential for conflicts and an associated need for conflict
>resolution strategies.
>
>
This is multimaster async replication.  But it can be further broken
down into four types:

1)  Insert-only, small number of nodes (not too hard to do with Slony-I).
2)  Insert-only, large number of nodes (a real pain to do with Slony-I,
could become unmanageable easily, but I suppose one could build
automated management tools)
3)  Insert/Update, small number of nodes.  Probably would require a
custom solution on top of Slony-I
4)  Insert/update, large number of nodes.  Not sure if this is possible
to manage effectively under any circumstances.

Best Wishes,
Chris Travers
Metatron Technoloy Consulting