Re: Sync Rep Design

On 12/31/2010 08:15 PM, Simon Riggs wrote:
> On Fri, 2010-12-31 at 14:40 +0200, Heikki Linnakangas wrote:
>> On 31.12.2010 13:48, Simon Riggs wrote:
>>>
>>> I see significant real-world issues with configuring replication using
>>> multiple named servers, as described in the link above:
>>
>> All of these points only apply to specifying *multiple* named servers in
>> the synchronous_standbys='...' list.
>
> Unfortunately, some of the points apply to using named servers ever,
> even if there is only one.
>
>> That's certainly a more complicated
>> scenario, and the configuration is more complicated as a result.
>> With your proposal, it's not possible in the first place.
>>
>> Multiple synchronous standbys probably isn't needed by most people, so
>> I'm fine with leaving that out for now, keeping the design the same
>> otherwise. I included it in the proposal because it easily falls out of
>> the design. So, if you're worried about the complexities of multiple
>> synchronous standbys, let's keep the UI exactly the same as what I
>> described in the link above, but only allow one name in the
>> synchronous_standbys setting, instead of a list.
>
> The best usage recommendation is still to have 2+ standbys, *any* of
> which can be used to provide sync rep. That is the best performance,
> best availability and easiest to configure that I know of. That best
> usage is not achievable with uniquely named servers; using non-unique
> names defeats the point of having names in the first place.

I disagree with that usage recommendation, if we ask for sync we should
get sync, your definition is more like "we should have fsync=on only do
fsync sometimes and still claim it is safe". Also it is very much
possible to do that semisync style replication feature with named
servers (see my post about the design I would like to see as a dba) and
STILL keep the flexibility to do what other people (like me) in that
thread want (at least from an UI perspective).
As I said before I would very much prefer to have us restricted to
exactly ONE sync capable standby and x async ones if we cannot agree on
a reasonable interface :(

>
> I accept that the "best usage" is a general case and there may be
> circumstances that make the difficulties of named servers worth the
> trouble.
>
> So replicating to multiple synchronous standbys is definitely needed in
> this release. *Confirming* replication to multiple named sync standbys
> is the thing we don't need in this release.

well you keep saying that but to be honest I cannot really even see a
usecase for me - what is "only a random one of a set of servers is sync
at any time and I don't really know which one".
My usecases would al involved 2 sync standbys and 1 or more async ones.
but the second sync one would be in a different datacenter and I NEED to
protect against a datacenter failure which your proposals says I cannot
do :(

Stefan