Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10(upgrading standby servers)
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10(upgrading standby servers) |
Дата | |
Msg-id | 20170912171922.GA3705@momjian.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10(upgrading standby servers) (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [HACKERS] Clarification in pg10's pgupgrade.html step 10(upgrading standby servers)
|
Список | 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@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? -- Bruce Momjian <bruce@momjian.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 + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Вложения
В списке pgsql-hackers по дате отправления: