Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)

On Mon, Jul 31, 2017 at 6:13 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Jul 28, 2017 at 10:35 AM, Andreas Joseph Krogh
> <andreas(at)visena(dot)com> wrote:
>> I'm reading https://www.postgresql.org/docs/10/static/pgupgrade.html to try
>> to understand how to upgrade standby-servers using pg_upgrade with pg10.
>>
>> The text in step 10 sais:
>> "You will not be running pg_upgrade on the standby servers, but rather
>> rsync", which to me sounds like rsync, in step 10-f, should be issued on the
>> standy servers. Is this the case? If so I don't understand how the standby's
>> data is upgraded and what "remote_dir" is. If rsync is supposed to be issued
>> on the primary then I think it should be explicitly mentioned, and step 10-f
>> should provide a clarer example with more detailed values for the
>> directory-structures involved.
>>
>> I really think section 10 needs improvement as I'm certainly not comfortable
>> upgrading standbys following the existing procedure.
>
> Yeah, I don't understand it either, and I have never been convinced
> that there's any safe way to do it other than recloning the standbys
> from the upgraded master.

Here are my 2c on the matter. 10-f means that the upgraded node may
have generated WAL with wal_level = minimal, which, at least it seems
to me, that we have a risk of having inconsistent data pages if only a
rsync is used on the old standbys. Like Robert, the flow we used in
the products I work on is to re-create standbys from scratch after the
upgrade using a fresh backup, with a VM cloning. An upgrade here is an
in-place process not only linked to Postgres, so standby VMs are made
of many services, some are being linked to Postgres. So this choice is
mainly decided by those dependencies, still it feels safer anyway.
--
Michael