MIME-Version: 1.0
References: 
 <CANNMO+KYuH3Gh7BZp=UGXpoos4tBR0AFgoONkqWBrokuJthEug@mail.gmail.com>
 <20181025111551.620c6460@firost> <20181025114557.GB1327@paquier.xyz>
 <20181025150351.629a68a1@firost>
In-Reply-To: <20181025150351.629a68a1@firost>
From: Nikolay Samokhvalov <samokhvalov@gmail.com>
Date: Thu, 25 Oct 2018 14:10:02 -0700
Message-ID: 
 <CANNMO+L1MtF3d-7y7pk6H5Wxt=G3ZRQn4QcNNQ0nS-713GxMCw@mail.gmail.com>
Subject: Re: Using old master as new replica after clean switchover
To: jgdr@dalibo.com
Cc: michael@paquier.xyz, pgsql-docs@lists.postgresql.org,
	pgsql-hackers@postgresql.org
Content-Type: multipart/alternative; boundary="0000000000007848f005791407fe"
Precedence: bulk

--0000000000007848f005791407fe
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 25, 2018 at 6:03 AM Jehan-Guillaume de Rorthais <jgdr@dalibo.co=
m>
wrote:

> What about logging the shutdown checkpoint on the old master?
> On the standby side, we could cross-check it with a function confirming:
> 1/ the very last XLogRecord received was the old master shutdown checkpoi=
nt
> 2/ the received shutdown checkpoint has the same LSN
>

Additionally, the new instructions in the doc might include recommendation,
what to do if we
found that shutdown checkpoint wasn't received and replayed by the
replica-to-promote. From my
understanding, before promotion, we could "manually" transfer missing WAL
data from the old,
inactive master and replay it on the replica-to-promote (of course, if
recovery_command is
properly configured on it). Right?

By the way, if it looks to me that it might be better to write more than
just few sentences, what if it
will be a new chapter =E2=80=93 say, "Switchover", next to "Failover". It w=
ould
also give better understanding
to the reading, explicitly distinguishing planned and unplanned processes
of master/replica role
changes.

Regards,
Nik

--0000000000007848f005791407fe
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thu, Oct 25, 2018 at 6:03 AM Jehan-Guillaume de Rorthai=
s &lt;<a href=3D"mailto:jgdr@dalibo.com">jgdr@dalibo.com</a>&gt; wrote:<br>=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What about logging the shutdown checkpoint on the old master?<br>
On the standby side, we could cross-check it with a function confirming:<br=
>
1/ the very last XLogRecord received was the old master shutdown checkpoint=
<br>
2/ the received shutdown checkpoint has the same LSN<br></blockquote><div><=
br></div><div>Additionally, the new instructions in the doc might include r=
ecommendation, what to do if we</div><div>found that shutdown checkpoint wa=
sn&#39;t received and replayed by the replica-to-promote. From my</div><div=
>understanding, before promotion, we could &quot;manually&quot; transfer mi=
ssing WAL data from the old,</div><div>inactive master and replay it on the=
 replica-to-promote (of course, if recovery_command is</div><div>properly c=
onfigured on it). Right?</div><div><br></div><div>By the way, if it looks t=
o me that it might be better to write more than just few sentences, what if=
 it</div><div>will be a new chapter =E2=80=93 say, &quot;Switchover&quot;, =
next to &quot;Failover&quot;. It would also give better understanding</div>=
<div>to the reading, explicitly distinguishing planned and unplanned proces=
ses of master/replica role</div><div>changes.</div><div><br></div><div>Rega=
rds,<br></div><div>Nik<br></div></div></div>

--0000000000007848f005791407fe--