From: Andreas Joseph Krogh <andreas@visena.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)
Date: Tue, 12 Sep 2017 20:59:05 +0200 (CEST)
Message-ID: <VisenaEmail.66.44a2ed6a4130e92c.15e776c27e4@tc7-visena> (raw)
In-Reply-To: <20170912171922.GA3705@momjian.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
På tirsdag 12. september 2017 kl. 19:19:22, skrev Bruce Momjian <
bruce@momjian.us <mailto:bruce@momjian.us>>:
On Thu, Aug 3, 2017 at 11:37:32AM +0200, Michael Paquier wrote:
> On Mon, Jul 31, 2017 at 6:13 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> > On Fri, Jul 28, 2017 at 10:35 AM, Andreas Joseph Krogh
> > <andreas@visena.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.
I have applied the attached doc patch back to 9.5 to clarify
pg_upgrade's rsync instructions and explain how it works.
Improvements?
Thanks, that certainly improves things.
But; I still find the rsync-command in f) confusing;
1. Why --size-only? From rsync manual: "skip files that match in size", is
this safe??
2. Why is old_pgdata in the rsync-command, why is it needed to sync it?
There are many ways to do/configure things it seems, resulting in many ifs and
buts which makes section 10 rather confusing. I really think a complete
example, with absolute paths, would be clarifying.
I'm afraid many will still re-create standbys from scratch without a really
good and complete example to follow.
--
Andreas Joseph Krogh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: andreas@visena.com, bruce@momjian.us, michael.paquier@gmail.com, robertmhaas@gmail.com
Subject: Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)
In-Reply-To: <VisenaEmail.66.44a2ed6a4130e92c.15e776c27e4@tc7-visena>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox