Re: Patch for fail-back without fresh backup - Mailing list pgsql-hackers

On 17 June 2013 09:03, Pavan Deolasee <pavan.deolasee@gmail.com> wrote:

> I agree. We should probably find a better name for this. Any suggestions ?

err, I already made one...

>> But that's not the whole story. I can see some utility in a patch that
>> makes all WAL transfer synchronous, rather than just commits. Some
>> name like synchronous_transfer might be appropriate. e.g.
>> synchronous_transfer = all | commit (default).

> Since commits are more foreground in nature and this feature
> does not require us to wait during common foreground activities, we want a
> configuration where master can wait for synchronous transfers at other than
> commits. May we can solve that by having more granular control to the said
> parameter ?
>
>>
>> The idea of another slew of parameters that are very similar to
>> synchronous replication but yet somehow different seems weird. I can't
>> see a reason why we'd want a second lot of parameters. Why not just
>> use the existing ones for sync rep? (I'm surprised the Parameter
>> Police haven't visited you in the night...) Sure, we might want to
>> expand the design for how we specify multi-node sync rep, but that is
>> a different patch.
>
>
> How would we then distinguish between synchronous and the new kind of
> standby ?

That's not the point. The point is "Why would we have a new kind of
standby?" and therefore why do we need new parameters?

> I am told, one of the very popular setups for DR is to have one
> local sync standby and one async (may be cascaded by the local sync). Since
> this new feature is more useful for DR because taking a fresh backup on a
> slower link is even more challenging, IMHO we should support such setups.

...which still doesn't make sense to me. Lets look at that in detail.

Take 3 servers, A, B, C with A and B being linked by sync rep, and C
being safety standby at a distance.

Either A or B is master, except in disaster. So if A is master, then B
would be the failover target. If A fails, then you want to failover to
B. Once B is the target, you want to failback to A as the master. C
needs to follow the new master, whichever it is.

If you set up sync rep between A and B and this new mode between A and
C. When B becomes the master, you need to failback from B from A, but
you can't because the new mode applied between A and C only, so you
have to failback from C to A. So having the new mode not match with
sync rep means you are forcing people to failback using the slow link
in the common case.

You might observe that having the two modes match causes problems if A
and B fail, so you are forced to go to C as master and then eventually
failback to A or B across a slow link. That case is less common and
could be solved by extending sync transfer to more/multi nodes.

It definitely doesn't make sense to have sync rep on anything other
than a subset of sync transfer. So while it may be sensible in the
future to make sync transfer a superset of sync rep nodes, it makes
sense to make them the same config for now.

Phew

--Simon Riggs                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services