Re: Replication on the backend - Mailing list pgsql-hackers

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
inplace.
 
  - 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,
itdivides again into    two camps. One is the idea to have one central system with thousands    of satellites (salesman
onthe 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@Yahoo.com #