Re: Behaviour of take over the synchronous replication

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Behaviour of take over the synchronous replication
Date: 2013-08-25 06:21:20
Message-ID: CAA4eK1J=mkYKTTP7qMSqKx3tHyPoZP_EahNkspkv3QdSEQ+FhQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Aug 24, 2013 at 2:46 PM, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com> wrote:
> On Sat, Aug 24, 2013 at 3:14 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>> On 08/23/2013 12:42 AM, Sawada Masahiko wrote:
>>> in case (a), those priority is clear. So I think that re-taking over
>>> is correct behaviour.
>>> OHOT, in case (b), even if AAA and BBB are set same priority, AAA
>>> server steals SYNC replication.
>>> I think it is better that BBB server continue behaviour SYNC standby,
>>> and AAA should become potential server.
>>
>> So, you're saying that:
>>
>> 1) synchronous_standby_names = '*'
>>
>> 2) replica 'BBB' is the current sync standby
>>
>> 3) replica 'AAA' comes online
>>
>> 4) replica 'AAA' grabs sync status
>>
>> ?
> I'm sorry that you are confuse.
> It means that
>
> 1) synchronous_standby_names = '*'
>
> 2) replica 'AAA' is the current sync standby
>
> 3) replica 'BBB' is the current async standby (potential sync standby)
>
> 4) replica 'AAA' fail. after that, replica 'BBB' is current sync standby.
>
> 5) replica 'AAA' comes online
>
> 6) replica 'AAA' grabs sync status
>
>>
>
>
>> If that's the case, I'm not really sure that's undesirable behavior.
>> One could argue fairly persuasively that if you care about the
>> precendence order of sync replicas, you shouldn't use '*'. And the rule
>> of "if using *, the lowest-sorted replica name has sync" is actually a
>> predictable, easy-to-understand rule.
>>
>> So if you want to make this a feature request, you'll need to come up
>> with an argument as to why the current behavior is bad. Otherwise,
>> you're just asking us to document it better (which is a good idea).
> It is not depend on name of standby server. That is, The standby server,
> which was connected to the master server during initial configration
> replication, is top priority even if priority of two server are same.

What is happening here is that incase of '*' as priority of both are
same, system will choose whichever
comes in list of registered standby's first (list is maintained in
structure WalSndCtl).
Each standby is registered with WalSndCtl when a new WALSender is
started in function InitWalSenderSlot().
As 'AAA' has been registered first it becomes preferred sync standby
even if priorities of both are same.
When 'AAA' goes down, it marks that Slot entry as free (by setting
pid=0 in function WalSndKill),
now when 'AAA' comes back again, it gets that free Slot entry and
again becomes preferred sync standby.

Now if we want to fix as you are suggesting which I don't think is
necessary, we might need to change WalSndKill and some other place so
that whenever any standby goes down, it changes slots for already
registered standby's.

> User must remember that which standby server connected to master server at
> first.
> I think that this behavior confuse user.
> so I think that we need to modify this behaviour or if '*' is used, priority
> of server is not same (modifying manual is also good).

Here user has done the settings (setting synchronous_standby_names =
'*'), after which he will not have any control which standby will
become sync standby, so ideally he should not complain.

It might be case that for some users current behavior is good enough
which means that with '*' whichever standby has become sync standby
first, it will be the sync standby always if alive.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc Cousin 2013-08-25 07:22:16 Re: Performance problem in PLPgSQL
Previous Message Amit Kapila 2013-08-25 05:00:53 Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])