Re: Replication on the backend

On 12/6/2005 8:10 AM, Markus Schiltknecht wrote:

> On Tue, 2005-12-06 at 10:03 -0200, Gustavo Tonini wrote:
>> But, wouldn't the performance be better? And wouldn't asynchronous
>> messages be better processed?
>
> At least for synchronous multi-master replication, the performance
> bottelneck is going to be the interconnect between the nodes -
> integration of the replication logic into the backend most probably
> doesn't affect performance that much.

That is exactly right. Thus far, processor, memory and disk speeds have
allways advanced on a higher pace than network speeds. Thus, the few
percent of performance gain we'd get from moving things into the backend
will be irrelevant tomorrow with 4x-core and 16x-core CPU's.

> I'd rather like to ask Jan what different needs for replication he
> discovered so far. And how he came to the conclusion, that it's not
> possible to provide a general solution.

- Asynchronous master to multi-slave. We have a few of those with
Mommoth-Replicator and Slony-I being the top players. Slony-I does
need some cleanup and/or reimplementation after we have a general
pluggable replication API in place.

- Synchronous multimaster. There are certain attempts out there, like
Postgres-R, pgcluster, Slony-II. Some more advanced, some less. But
certainly nothing I would send into the ring against Oracle-Grid.

- Asynchronous multimaster with conflict resolution. I have not seen
any reasonable attempt on this one yet. Plus, it divides again into
two camps. One is the idea to have one central system with thousands
of satellites (salesman on the street), the other being two or more
central systems doing load balancing (although this competes with
sync-mm).

> My point for integration into the backend is flexibility: obviously the
> replication code can influence the database much more from within the

We need a general API. It should be possible to define on a per-database
level which shared replication module to load on connect. The init
function of that replication module then installs all the required
callbacks at strategic points (like heap_update(), at_commit() ...) and
the rest is hidden in the module.

> Is there some discussion going on about such topics somewhere? What's up
> with slony-2? The wiki on slony2.org still doesn't provide a lot of
> technical information (and obviously got spammed BTW).

Slony-II has been slow lately in the Eastern timezone.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #