> 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. ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
