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>
Cc: Stephen Frost <sfrost@snowman.net>
Subject: Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)
Date: Fri, 15 Sep 2017 01:23:45 +0200 (CEST)
Message-ID: <VisenaEmail.db.e5ceedc56ec1471.15e82123988@tc7-visena> (raw)
In-Reply-To: <20170914191356.GC6595@momjian.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
På torsdag 14. september 2017 kl. 21:13:56, skrev Bruce Momjian <
bruce@momjian.us <mailto:bruce@momjian.us>>:
On Thu, Sep 14, 2017 at 08:49:24PM +0200, Andreas Joseph Krogh wrote:
> I think the tablespace example is clear enough to modify for WAL and we
> instruct them right below that example to do WAL.
>
>
> Well, it's not following the exact same structure as there's no
> "version-directory" in pg_xlog, so the "rsync the version-dirs into it's
parent
> on the target" isn't what's happening.
>
> That's why I think this makes sense to mention for the sake of a complete
> example:
>
> rsync --archive --delete --hard-links --size-only
/vol1/postgres/9.6/pg_xlog \
> /vol1/postgres/10/pg_wal standby.example.com:/vol1/postgres/10/pg_wal
Well, there is technically no need for version directories in pgdata
either --- installers just create them.
I tested upgrading from 9.6 to 10 now, using pg_upgrade, and pg_upgrade
creates the new data-dir with pg_wal "in it" (just like regular initdb), so
pg_upgrade seems not to care about where the old version's pg_xlog was. You
have to move (by symlinking) pg_wal to a separate location manually *after*
running pg_upgrade on the master. No special handling is needed when rsync'ing
it over to the standby, so it doesn't need any --hard-links or --size-only,
correct?
Given the path, on the upgraded primary, to pg_wal is /custom/path/to/pg_wal,
the rsync command will be:
rsync --archive --delete /custom/path/to/pg_wal
standby.example.com:/custom/path/to/pg_wal
I think it's useful to mention this to eliminate any doubt.
I also think it's worth mentioning that you have to manually move pg_wal to a
custom location after running pg_upgrade as it will not preserve/use the old
path.
Thanks.
--
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, sfrost@snowman.net
Subject: Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)
In-Reply-To: <VisenaEmail.db.e5ceedc56ec1471.15e82123988@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