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