On Tue, 2010-05-25 at 11:52 -0500, Kevin Grittner wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
> > Simon Riggs <simon@2ndquadrant.com> wrote:
> >> If we define robustness at the standby level then robustness
> >> depends upon unseen administrators, as well as the current
> >> up/down state of standbys. This is action-at-a-distance in its
> >> worst form.
> >
> > Maybe, but I can't help thinking people are going to want some
> > form of this. The case where someone wants to do sync rep to the
> > machine in the next rack over and async rep to a server at a
> > remote site seems too important to ignore.
>
> I think there may be a terminology issue here -- I took "configure
> by standby" to mean that *at the master* you would specify rules for
> each standby. I think Simon took it to mean that each standby would
> define the rules for replication to it. Maybe this issue can
> resolve gracefully with a bit of clarification?
The use case of "machine in the next rack over and async rep to a server
at a remote site" would require the settings
server.nextrack = synch
server.remotesite = async
which leaves open the question of what happens when "nextrack" is down.
In many cases, to give adequate performance in that situation people add
an additional server, so the config becomes
server.nextrack1 = synch
server.nextrack2 = synch
server.remotesite = async
We then want to specify for performance reasons that we can get a reply
from either nextrack1 or nextrack2, so it all still works safely and
quickly if one of them is down. How can we express that rule concisely?
With some difficulty.
My suggestion is simply to have a single parameter (name unimportant)
number_of_synch_servers_we_wait_for = N
which is much easier to understand because it is phrased in terms of the
guarantee given to the transaction, not in terms of what the admin
thinks is the situation.
-- Simon Riggs www.2ndQuadrant.com