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
