Re: Synchronization levels in SR - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Synchronization levels in SR
Date
Msg-id 4BFD94DC.40904@enterprisedb.com
Whole thread Raw
In response to Re: Synchronization levels in SR  (Dimitri Fontaine <dfontaine@hi-media.com>)
Responses Re: Synchronization levels in SR
Re: Synchronization levels in SR
Re: Synchronization levels in SR
List pgsql-hackers
On 26/05/10 23:31, Dimitri Fontaine wrote:
> So if you want simplicity to admin, effective data availability and
> precise control over the global setup, I say go for:
>   a. transaction level control of the replication level
>   b. cascading support
>   c. quorum with timeout
>   d. choice of commit or rollback at timeout
>
> Then give me a setup example that you can't express fully.

One master, one synchronous standby on another continent for HA 
purposes, and one asynchronous reporting server in the same rack as the 
master. You don't want to set up the reporting server as a cascaded 
slave of the standby on the other continent, because that would double 
the bandwidth required, but you also don't want the master to wait for 
the reporting server.

The possibilities are endless... Your proposal above covers a pretty 
good set of scenarios, but it's by no means complete. If we try to solve 
everything the configuration will need to be written in a 
Turing-complete Replication Description Language. We'll have to pick a 
useful, easy-to-understand subset that covers the common scenarios. To 
handle the more exotic scenarios, you can write a proxy that sits in 
front of the master, and implements whatever rules you wish, with the 
rules written in C.

BTW, I think we're going to need a separate config file for listing the 
standbys anyway. There you can write per-server rules and options, but 
explicitly knowing about all the standbys also allows the master to 
recycle WAL as soon as it has been streamed to all the registered 
standbys. Currently we just keep wal_keep_segments files around, just in 
case there's a standby out there that needs them.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Bernd Helmle
Date:
Subject: Re: ALTER TABLE...ALTER COLUMN vs inheritance
Next
From: Heikki Linnakangas
Date:
Subject: Re: primary/secondary/master/slave/standby