From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andreas Joseph Krogh <andreas(at)visena(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers) |
Date: | 2017-09-12 17:19:22 |
Message-ID: | 20170912171922.GA3705@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(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.
I have applied the attached doc patch back to 9.5 to clarify
pg_upgrade's rsync instructions and explain how it works.
Improvements?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
Attachment | Content-Type | Size |
---|---|---|
diff | text/x-diff | 5.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2017-09-12 17:23:55 | Re: psql - add special variable to reflect the last query status |
Previous Message | Robert Haas | 2017-09-12 17:17:58 | domain type smashing is expensive |