diff options
| -rw-r--r-- | doc/src/sgml/ref/pgupgrade.sgml | 41 |
1 files changed, 24 insertions, 17 deletions
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml index 60011d8167a..146b3af6203 100644 --- a/doc/src/sgml/ref/pgupgrade.sgml +++ b/doc/src/sgml/ref/pgupgrade.sgml @@ -320,20 +320,14 @@ NET STOP postgresql-&majorversion; <title>Prepare for standby server upgrades</title> <para> - If you are upgrading standby servers (as outlined in section <xref - linkend="pgupgrade-step-replicas">), verify that the old standby + If you are upgrading standby servers using methods outlined in section <xref + linkend="pgupgrade-step-replicas">, verify that the old standby servers are caught up by running <application>pg_controldata</> against the old primary and standby clusters. Verify that the <quote>Latest checkpoint location</> values match in all clusters. (There will be a mismatch if old standby servers were shut down before the old primary.) </para> - - <para> - Also, if upgrading standby servers, change <varname>wal_level</> - to <literal>replica</> in the <filename>postgresql.conf</> file on - the new primary cluster. - </para> </step> <step> @@ -423,12 +417,18 @@ pg_upgrade.exe <para> If you used link mode and have Streaming Replication (see <xref linkend="streaming-replication">) or Log-Shipping (see <xref - linkend="warm-standby">) standby servers, follow these steps to - upgrade them. You will not be running <application>pg_upgrade</> on + linkend="warm-standby">) standby servers, you can follow these steps to + quickly upgrade them. You will not be running <application>pg_upgrade</> on the standby servers, but rather <application>rsync</> on the primary. - Do not start any servers yet. If you did <emphasis>not</> use link - mode, skip the instructions in this section and simply recreate the - standby servers. + Do not start any servers yet. + </para> + + <para> + If you did <emphasis>not</> use link mode, do not have or do not + want to use <application>rsync</>, or want an easier solution, skip + the instructions in this section and simply recreate the standby + servers once <application>pg_upgrade</> completes and the new primary + is running. </para> <substeps> @@ -448,7 +448,7 @@ pg_upgrade.exe <para> Make sure the new standby data directories do <emphasis>not</> exist or are empty. If <application>initdb</> was run, delete - the standby server data directories. + the standby servers' new data directories. </para> </step> @@ -474,9 +474,10 @@ pg_upgrade.exe <title>Save configuration files</title> <para> - Save any configuration files from the standbys you need to keep, - e.g. <filename>postgresql.conf</>, <literal>recovery.conf</>, - as these will be overwritten or removed in the next step. + Save any configuration files from the old standbys' data + directories you need to keep, e.g. <filename>postgresql.conf</>, + <literal>recovery.conf</>, because these will be overwritten or + removed in the next step. </para> </step> @@ -507,6 +508,12 @@ rsync --archive --delete --hard-links --size-only /opt/PostgreSQL/9.5/data \ /opt/PostgreSQL/9.6/data standby.example.com:/opt/PostgreSQL </programlisting> + You can verify what the command will do using + <application>rsync</>'s <option>--dry-run</> option. While + <application>rsync</> must be run on the primary for at least one + standby, it is possible to run <application>rsync</> on an upgraded + standby to upgrade other standbys, as long as the upgraded standby + has not been started. </para> <para> |