pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedstandby upgrade questions
2+ messages / 2 participants
[nested] [flat]
* standby upgrade questions
@ 2017-10-17 15:34 Ray Stell <stellr@vt.edu>
2018-01-29 03:35 ` Re: [ADMIN] standby upgrade questions Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 2+ messages in thread
From: Ray Stell @ 2017-10-17 15:34 UTC (permalink / raw)
To: pgsql-admin
From: https://www.postgresql.org/docs/9.6/static/pgupgrade.html
Q1 - Is there a procedure to force this "catch up?" I suppose
preventing db activity with a pg_hba hack and running "select
pg_switch_xlog()." Maybe there's a better way?
1.
Prepare for standby server upgrades
If you are upgrading standby servers (as outlined in sectionstep 10
<https://www.postgresql.org/docs/9.6/static/pgupgrade.html#PGUPGRADE-STEP-REPLICAS;),
verify that the old standby servers are caught up by
runningpg_controldataagainst the old primary and standby clusters.
Verify that the"Latest checkpoint location"values match in all
clusters. (There will be a mismatch if old standby servers were shut
down before the old primary.)
Also, if upgrading standby servers, changewal_leveltoreplicain
thepostgresql.conffile on the new master cluster.
Q2 - I was wondering what the end result is, in general, of this rsync
of old and new? If the old db files and upgraded, new db files are
meshed what do you get on the other side of the rsync? Again, I mean in
general what is the goal?
f. Runrsync
From a directory that is above the old and new database cluster
directories, run this for each slave:
rsync --archive --delete --hard-links --size-only old_pgdata new_pgdata remote_dir
whereold_pgdataandnew_pgdataare relative to the current directory,
andremote_dirisabovethe old and new cluster directories on the standby
server. The old and new relative cluster paths must match on the master
and standby server.
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: [ADMIN] standby upgrade questions
2017-10-17 15:34 standby upgrade questions Ray Stell <stellr@vt.edu>
@ 2018-01-29 03:35 ` Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 2+ messages in thread
From: Bruce Momjian @ 2018-01-29 03:35 UTC (permalink / raw)
To: Ray Stell <stellr@vt.edu>; +Cc: pgsql-admin
On Tue, Oct 17, 2017 at 11:34:51AM -0400, Ray Stell wrote:
> From: https://www.postgresql.org/docs/9.6/static/pgupgrade.html
Sorry for the late reply.
> Q1 - Is there a procedure to force this "catch up?" I suppose preventing db
> activity with a pg_hba hack and running "select pg_switch_xlog()." Maybe
> there's a better way?
Uh, if there was a better way than pg_hba.conf, we would document it.
Do you have any ideas?
> 1. Prepare for standby server upgrades
>
> If you are upgrading standby servers (as outlined in section step 10),
> verify that the old standby servers are caught up by running pg_controldata
> against the old primary and standby clusters. Verify that the "Latest
> checkpoint location" values match in all clusters. (There will be a
> mismatch if old standby servers were shut down before the old primary.)
>
> Also, if upgrading standby servers, change wal_level to replica in the
> postgresql.conf file on the new master cluster.
>
>
> Q2 - I was wondering what the end result is, in general, of this rsync of old
> and new? If the old db files and upgraded, new db files are meshed what do you
> get on the other side of the rsync? Again, I mean in general what is the goal?
I added more detail on what happens with rsync in this commit:
commit 2d4a614e1ec34a746aca43d6a02aa3344dcf5fd4
Author: Bruce Momjian <bruce@momjian.us>
Date: Tue Sep 12 13:17:52 2017 -0400
docs: improve pg_upgrade rsync instructions
This explains how rsync accomplishes updating standby servers and
clarifies the instructions.
Reported-by: Andreas Joseph Krogh
Discussion: https://postgr.es/m/VisenaEmail.10.2b4049e43870bd16.15d898d696f@tc7-visena
Backpatch-through: 9.5
The new text is:
https://www.postgresql.org/docs/10/static/pgupgrade.html
What this does is to record the links created by pg_upgrade's link mode
that connect files in the old and new clusters on the primary server. It
then finds matching files in the standby's old cluster and creates links
for them in the standby's new cluster. Files that were not linked on the
primary are copied from the primary to the standby. (They are usually
small.) This provides rapid standby upgrades. Unfortunately, rsync
needlessly copies files associated with temporary and unlogged tables
because these files don't normally exist on standby servers.
--
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 +
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2018-01-29 03:35 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-10-17 15:34 standby upgrade questions Ray Stell <stellr@vt.edu>
2018-01-29 03:35 ` Bruce Momjian <bruce@momjian.us>
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