Simon Riggs <simon@2ndQuadrant.com> writes:
> On Wed, 2010-05-26 at 19:55 +0300, Heikki Linnakangas wrote:
>> Now you want to set up a temporary replica of the master at a
>> development server, for testing purposes. If you set quorum to 2, your
>> development server becomes critical infrastructure, which is not what
>> you want.
>
> That's a good argument for standby relays.
Well it seems to me we can have the best of both worlds as soon as we
have cascading support. Even in the test server example, this one would
be a slave of the main slave, not counted into the quorum on the master.
Now that's the quorum on the slave that would be deciding on the
availability of the test server. Set it down to 0 and your test server
has no impact on the production environment.
In the example of one master and 4 slaves in 2 different locations,
you'll have a quorum of 2 on the master, which will know about 2 slaves
only. And each of them will have 1 slave, with a quorum to set to 0 or 1
depending on what you want to achieve.
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 levelb. cascading
supportc.quorum with timeoutd. choice of commit or rollback at timeout
Then give me a setup example that you can't express fully.
As far as the options to control the whole thing are concerned, I think
that the cascading support does not add any. So that's 3 GUCs.
Regards,
--
dim
