From: Markus Schiltknecht <markus@bluegap.ch>
To: Chris Browne <cbbrowne@acm.org>
Subject: Re: Replication - super-draft
Date: Tue, 25 Jul 2006 20:50:18 +0200
Message-ID: <44C667EA.7080309@bluegap.ch> (raw)
In-Reply-To: <60hd15br5y.fsf@dba2.int.libertyrms.com>
References: <6064hmd7vn.fsf_-_@dba2.int.libertyrms.com>
<44C60198.6070008@bluegap.ch>
<60hd15br5y.fsf@dba2.int.libertyrms.com>
Hi,
Chris Browne wrote:
> Under conditions where one expects to see a lot of conflicting
> updates, pushing out locks earlier would allow sooner discovery of
> these conflicts; whether this improves or worsens total performance is
> at least a bit ambiguous.
That's a good point, yes. Given one gets lots of conflicts, one should
probably go for async (or single master) replication anyway. (Or see the
performance degrade below single-node operation, which is imaginable for
both approaches, IMHO. Finally, only benchmarking will tell.)
[ In single node operation, we have READ COMMITTED vs. SERIALIZABLE,
which is pessimistic vs. optimistic. Correct me if I'm wrong, but in
general I thought, optimistic locking (SERIALIZABLE) is prefered and
leads to better performance. That's why came to think the same holds
true for replication. Or is READ COMMITTED better if you have lots of
conflicting transactions? Any numbers on that? ]
Coming back to thinking about the replicaiton doc... the draft describes
the different types of replication very well. But no all users will
immediately see what each type is good for. Therefore we should probably
also cover some use cases, i.e. what type of replication to use when.
The most frequently asked use case probably being a hot-backup with
failover capability -> single-master, async / sync, depending on your
needs. Another use case could probably describe a multi-master scenario
and outline pros and cons of that (perhaps gently touching the above issue?)
Another issue that comes to mind: PgCluster2 targets shared-disk
clusters, a significant difference to shared-nothing clusters. Maybe
that gives another paragraph under 'categorization'?
Given that additional categorization: should the use cases be added per
replication solution?
>> A nit-picking detail: I'm unsure about the correct english spelling of
>> single- and multi-master ('single master', 'single-master' or
>> 'singlemaster'), but please make sure to use a consistent spelling.
>
> That is indeed useful editorial guidance...
Sorry, I must have felt super clever. ;-) Although... as a non native
english speaker, I would still like to know the preferred spelling.
Regards
Markus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: markus@bluegap.ch, cbbrowne@acm.org
Subject: Re: Replication - super-draft
In-Reply-To: <44C667EA.7080309@bluegap.ch>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox