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

From: Andreas Joseph Krogh <andreas(at)visena(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>
Subject: Re: Clarification in pg10's pgupgrade.html step 10 (upgrading standby servers)
Date: 2017-09-16 21:36:40
Message-ID: VisenaEmail.168.7a4f8a0ead2e6636.15e8c678c2f@tc7-visena
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

På lørdag 16. september 2017 kl. 18:34:51, skrev Bruce Momjian <bruce(at)momjian(dot)us
<mailto:bruce(at)momjian(dot)us>>:
On Sat, Sep 16, 2017 at 06:11:17PM +0200, Andreas Joseph Krogh wrote:
> I'm a little unsure what scenario we're trying to describe here. Copying the
> pg_wal separately (for which there's no need optimizing for) is only needed
if
> you've moved it out of $PGDATA _after_ running pg_upgrade, IIUC. So, I
think it

No.  If you ran initdb with --waldir on the new primary, you will create
a symbolic link in the PGDATA directory, and a directory outside of
PGDATA for storing the WAL.  When you run rsync on the new primary
PGDATA directory, you will copy the symlink in the PGDATA directory, but
it will point to probably nothing on the standby.
 
 
The misunderstanding here comes from the fact that I used pg_upgradecluster
like this:
pg_upgradecluster --method=upgrade --link 9.6 main
 
and it didn't issue initdb with --waldir on the new cluster (because
pg_upgradecluster issues initdb for you), so pg_wal ended up in $PGDIR because
pg_upgradecluster didn't figure out the old cluster was initialized with
--xlogdir. This is why I thought i made sense mentioning that one had to move
pg_wal manually.
 
I know it's debian-stuff, but maybe it's worth mentioning pg_upgradecluster
somewhere and recommend not using it? It seems to start the new cluster
automatically and when upgrading standbys section 10 tells you not to do that.
 
 
> should be clearly pointed out that copying pg_wal is only needed in those
> cases, and that it can be done with whatever network-copying procedure
you're
> familiar with, ie. scp/rsync. This step is not similar to the steps required
> for copying tablespaces outside $PGDATA, so it's worth documenting
explicitly.
> Maybe also telling users to ensure the synlink (in $PGDATA) to pg_wal on
> standby points to pg_wal.

Why tell them new instructions when the rsync instructions work fine?
What is the value?
 
The rsync instructions mentioned in 10.F all address the --link scenario and
use "--delete --hard-links --size-only", and "merge 2 source-dirs into one",
which isn't relevant when copying pg_wal.
 
This sentence:
"If you have relocated pg_wal outside the data directories, rsync must be run
on those directories too."
implies one must follow the rsync pattern elsewhere in 10.F, which isn't
really true. Maybe re-wording it to:
"If you have relocated pg_wal outside the data directories you must copy it
over to the new standby, and ensure the symlink from $PGDATA points to it"
helps?

--
Andreas Joseph Krogh

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-09-16 21:58:26 Re: Pre-existing bug in trigger.c
Previous Message David Rowley 2017-09-16 21:28:44 Re: [GENERAL] Remove useless joins (VARCHAR vs TEXT)