On Fri, Feb 10, 2017 at 7:15 PM, Jehan-Guillaume de Rorthais
<ioguix@free.fr> wrote:
> On Thu, 9 Feb 2017 18:27:30 +0000
> Rakesh Kumar <rakeshkumar464@outlook.com> wrote:
>
>> >Sure, but when you are doing a switchover, the standby is supposed to be
>> >connected to the master when you shutdown the master. So based on the doc,
>> >the standby should receive **everything** from the master before the master
>> >actually shutdown.
>>
>> We use 9.5 and even in that version there is no handshake during role
>> reversal. In fact PG does not have concept of handshake and role reversal
>> unlike in Db2, oracle and sqlserver you can switchover from one to other by a
>> single command.
>>
>> Our DBAs use home grown script for switchover which does the following:
>>
>> 1 - first kill postmaster in the outgoing primary.
>
> Kill ? You mean "pg_ctl stop -m fast" right ?
If at shutdown the previous primary does not issue a checkpoint, there
is no way to be sure that it will begin replaying WAL from the point
after WAL has forked. In short, if you kill it, then try to connect it
back to the new promoted primary, it may be able to begin replicating
changes. And if at the moment it was killed an unfinished checkpoint
was running, you will much likely corrupt a couple of pages on your
primary.
>> 2 - promote the standby as the new primary
>> 3 - use timeline to resync former primary (of step 1) with the new primary
>> (step 2).
>
> Use timeline to resync ? Timeline is an internal mechanism in PostgreSQL, not
> a tool, so I don't get this step...You mean using pg_rewind ?
>
> So far, I stick to my procedure (given in another answer) which looks a lot
> more safer.
Definitely yes, Guillaune is right here. You need to rewind things.
After being sure that the previous primary has been stopped cleanly.
You could as well kill it once if you want to make your server go down
as fast as possible once. But at next startup let it recover
completely, then stop it cleanly, and finally you will be able to
recycle it consistently with pg_rewind.
--
Michael
