Re: Clean switchover - Mailing list pgsql-hackers

From Mark Kirkwood
Subject Re: Clean switchover
Date
Msg-id 51BA76D2.4030906@catalyst.net.nz
Whole thread Raw
In response to Re: Clean switchover  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On 14/06/13 07:38, Fujii Masao wrote:
> On Wed, Jun 12, 2013 at 12:55 PM, Mark Kirkwood
> <mark.kirkwood@catalyst.net.nz> wrote:
>> On 12/06/13 13:15, Stephen Frost wrote:
>>>
>>> * Fujii Masao (masao.fujii@gmail.com) wrote:
>>>>
>>>> The attached patch fixes this problem. It just changes walsender so that
>>>> it
>>>> waits for all the outstanding WAL records to be replicated to the standby
>>>> before closing the replication connection.
>>>
>>>
>>> Seems like a good idea to me..  Rather surprised that we're not doing
>>> this already, to be honest.
>>>
>>
>> Yeah +1 from here too. This would make clean switchovers for (typically)
>> testing scenarios a lot less complex and resource intensive (rebuilding of
>> the old master as a slave when you know it is ok is despairing on a huge
>> db).
>>
>> On the related note (but not actually to do with this patch),
>> clarifying/expanding the docs about the various methods for standby
>> promotion:
>>
>> 1/ trigger file creation
>> 2/ pg_ctl promote
>> 3/ renaming/removing recovery.conf
>>
>> and the differences between them would be great. For instance I only
>> recently realized that method 3) means the promoted standby does not start a
>> new timeline (incidentally - could this be an option to pg_ctl promote)
>> which is very useful for (again) controlled/clean switchovers.
>
> In 9.3, you no longer need to worry about the increment of timeline
> after the promotion because the standby can automatically follow
> the timeline switch.
>
> Regards,
>

Yes - and that will be awesome. Nice work!

However for those systems still on 9.1/9.2for the time being, some 
clarification of the details/differences uisg promotion via the 1) - 3) 
would be useful I think.

Note I'm not demanding that you do it - I just happened to be thinking 
about this when I saw your patch, so though I'd mention it (I've seen 
some brief discussion about this before, but nothing concrete came out 
of that in terms of documentation additions).

If folks are keen, I'm willing to attempt to find a suitable place in 
the docs to add a discussion about 1) - 3) above. However I was kinda 
hoping that someone who knows all the details would... fro instance I've 
skimmed the code and note that the system "knows" when it is promoted 
via trigger file vs pg_ctl... but as to what if any differences that 
makes to the resulting actions (other than removing the trigger file) - 
I am not clear on.

Cheers

Mark



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Adjusting elog behavior in bootstrap/standalone mode
Next
From: Peter Eisentraut
Date:
Subject: [PATCH] Add transforms feature