Re: Clean switchover

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clean switchover
Date: 2013-06-14 01:50:10
Message-ID: 51BA76D2.4030906@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 14/06/13 07:38, Fujii Masao wrote:
> On Wed, Jun 12, 2013 at 12:55 PM, Mark Kirkwood
> <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> wrote:
>> On 12/06/13 13:15, Stephen Frost wrote:
>>>
>>> * Fujii Masao (masao(dot)fujii(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2013-06-14 03:11:41 [PATCH] Add transforms feature
Previous Message Stephen Frost 2013-06-14 01:33:02 Re: Adjusting elog behavior in bootstrap/standalone mode