+ linkend="warm-standby">) standby servers, follow these steps to
+ upgrade them (before starting any servers):
+
+
+
+
+
Install the new PostgreSQL binaries on standby servers
+
+ Make sure the new binaries and support files are installed on all
+ standby servers.
+
+
+
+
+
Make sure the new standby data directories do <emphasis>not</></div>
<div class="diff add">+ exist
+
+ Make sure the new standby data directories do not
+ exist or are empty. If
initdb was run, delete+ the standby server data directories.
+
+
+
+
+
Install custom shared object files
+
+ Install the same custom shared object files on the new standbys
+ that you installed in the new master cluster.
+
+
+
+
+
Stop standby servers
+
+ If the standby servers are still running, stop them now using the
+ above instructions.
+
+
+
+
+
Verify standby servers
+
+ To prevent old standby servers from being modified, run
+
pg_controldata against the primary and standby+ clusters and verify that the Latest checkpoint location
+ values match in all clusters. (This requires the standbys to be
+ shut down after the primary.)
+
+
+
+
+
Save configuration files
+
+ Save any configuration files from the standbys you need to keep,
+ e.g. postgresql.conf, recovery.conf,
+ as these will be overwritten or removed in the next step.
+
+
+
+
+
Start and stop the new master cluster
+
+ In the new master cluster, change wal_level to
+ hot_standby in the postgresql.conf file
+ and then start and stop the cluster.
+
+
+
+
+
Run <application>rsync</>
+
+ 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
+
+
+ where
+ to the current directory, and
+ above the old and new cluster directories on
+ the standby server. The old and new relative cluster paths
+ must match on the master and standby server. Consult the
+
rsync manual page for details on specifying the+ remote directory, e.g. standbyhost:/opt/PostgreSQL/.
+
rsync will be fast when pg_upgrade's+
+ on the remote server rather than transferring user data.
+
+
+ If you have tablespaces, you will need to run a similar
+
rsync command for each tablespace directory. If you+ have relocated pg_xlog outside the data directories,
+
rsync must be run on those directories too.+
+
+
+
+
Configure streaming replication and log-shipping standby</div>
<div class="diff add">+ servers
+
+ Configure the servers for log shipping. (You do not need to run
+ pg_start_backup() and pg_stop_backup()
+ or take a file system backup as the slaves are still synchronized
+ with the master.)
+
+
+
+
+
+
+
Restore <filename>pg_hba.conf</>
+
+
Start the new server
+
+ The new server can now be safely started, and then any
+
rsync'ed standby servers.+
+
+
Post-Upgrade processing
location. (This is not relevant on Windows.)
- A Log-Shipping Standby Server () cannot
- be upgraded because the server must allow writes. The simplest way
- is to upgrade the primary and use rsync to rebuild the
- standbys. You can run rsync while the primary is down,
- or as part of a base backup ()
- which overwrites the old standby cluster.
-
-
If you want to use link mode and you do not want your old cluster
to be modified when the new cluster is started, make a copy of the
old cluster and upgrade that in link mode. To make a valid copy
of the old cluster, use rsync to create a dirty
copy of the old cluster while the server is running, then shut down
- the old server and run rsync again to update the copy with any
- changes to make it consistent. You might want to exclude some
+ the old server and run rsync --checksum again to update the
+ copy with any changes to make it consistent. (
+ is necessary because rsync only has file modification-time
+ granularity of one second.) You might want to exclude some
files, e.g.
postmaster.pid, as documented in
linkend="backup-lowlevel-base-backup">. If your file system supports
file system snapshots or copy-on-write file copies, you can use that
projects / postgresql.git / commitdiff