Re: Replication - super-draft - Mailing list pgsql-docs

From Markus Schiltknecht
Subject Re: Replication - super-draft
Date
Msg-id 44C667EA.7080309@bluegap.ch
Whole thread Raw
In response to Re: Replication - super-draft  (Markus Schiltknecht <markus@bluegap.ch>)
List pgsql-docs
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


pgsql-docs by date:

Previous
From: Markus Schiltknecht
Date:
Subject: Re: Replication - super-draft
Next
From: Devrim GUNDUZ
Date:
Subject: New 8.1.4 PDF