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
begin:vcard
fn:Chris Travers
n:Travers;Chris
email;internet:chris@xxxxxxxxxxxxxxxx
x-mozilla-html:FALSE
version:2.1
end:vcard
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
