Re: Replicating databases

> On Thu, Nov 03, 2005 at 04:49:33PM -0500, Andrew Sullivan wrote:
>> On Wed, Nov 02, 2005 at 05:23:34PM -0600, Jim C. Nasby wrote:
>> > > It seems kludgey this way, though. What you really need is
>> > > multimaster with conflict resolution, because you can depend on your
>> >
>> > Isn't Slony2 supposed to do just that?
>>
>> Well, to the extent that slony 2 ever is going to do anything, our
>> original aim was multimaster replication in a single data centre.
>> Some folks have been working on various approaches that seem to be
>> bearing real bitter fruit, though, and I don't know how hopeful I am
>> these days for a general-purpose tool that will do that.
>
> How were you going about it such that it would matter if it was in a
> local data center or not?

The approach under examination bears "remarkable similarity" to the
Postgres-R work at McGill University.

The notion is that transactions are not permitted to commit until they
are ready to commit on all of the servers.

Normally, you'd expect that to be some form of 2 Phase Commit. There
are some unfortunate things about 2PC that it tries to avoid...

The cleverness is in trying to propagate lock requests as early as
possible in processing (whereas 2PC seems to push a lot of work right
to the END of the transaction).

In essence, this is a "fairly nearly synchronous" replication model.

The result of the "near synchronicity" is that it could only possibly
perform well if all "masters" are in the same local network. If you
introduce a far-away host that has 2 second latency, that introduces 2
seconds of latency to *every* transaction processed on the system.

Bye, bye, performance...
--
(reverse (concatenate 'string "moc.liamg" "@" "enworbbc"))
http://cbbrowne.com/info/
If we were meant to fly, we wouldn't keep losing our luggage.