@@ -320,20 +320,14 @@ NET STOP postgresql-9.0
320
320
<title>Prepare for standby server upgrades</title>
321
321
322
322
<para>
323
- If you are upgrading standby servers (as outlined in section <xref
324
- linkend="pgupgrade-step-replicas">) , verify that the old standby
323
+ If you are upgrading standby servers using methods outlined in section <xref
324
+ linkend="pgupgrade-step-replicas">, verify that the old standby
325
325
servers are caught up by running <application>pg_controldata</>
326
326
against the old primary and standby clusters. Verify that the
327
327
<quote>Latest checkpoint location</> values match in all clusters.
328
328
(There will be a mismatch if old standby servers were shut down
329
329
before the old primary.)
330
330
</para>
331
-
332
- <para>
333
- Also, if upgrading standby servers, change <varname>wal_level</>
334
- to <literal>replica</> in the <filename>postgresql.conf</> file on
335
- the new primary cluster.
336
- </para>
337
331
</step>
338
332
339
333
<step>
@@ -423,12 +417,18 @@ pg_upgrade.exe
423
417
<para>
424
418
If you used link mode and have Streaming Replication (see <xref
425
419
linkend="streaming-replication">) or Log-Shipping (see <xref
426
- linkend="warm-standby">) standby servers, follow these steps to
427
- upgrade them. You will not be running <application>pg_upgrade</> on
420
+ linkend="warm-standby">) standby servers, you can follow these steps to
421
+ quickly upgrade them. You will not be running <application>pg_upgrade</> on
428
422
the standby servers, but rather <application>rsync</> on the primary.
429
- Do not start any servers yet. If you did <emphasis>not</> use link
430
- mode, skip the instructions in this section and simply recreate the
431
- standby servers.
423
+ Do not start any servers yet.
424
+ </para>
425
+
426
+ <para>
427
+ If you did <emphasis>not</> use link mode, do not have or do not
428
+ want to use <application>rsync</>, or want an easier solution, skip
429
+ the instructions in this section and simply recreate the standby
430
+ servers once <application>pg_upgrade</> completes and the new primary
431
+ is running.
432
432
</para>
433
433
434
434
<substeps>
@@ -448,7 +448,7 @@ pg_upgrade.exe
448
448
<para>
449
449
Make sure the new standby data directories do <emphasis>not</>
450
450
exist or are empty. If <application>initdb</> was run, delete
451
- the standby server data directories.
451
+ the standby servers' new data directories.
452
452
</para>
453
453
</step>
454
454
@@ -474,9 +474,10 @@ pg_upgrade.exe
474
474
<title>Save configuration files</title>
475
475
476
476
<para>
477
- Save any configuration files from the standbys you need to keep,
478
- e.g. <filename>postgresql.conf</>, <literal>recovery.conf</>,
479
- as these will be overwritten or removed in the next step.
477
+ Save any configuration files from the old standbys' data
478
+ directories you need to keep, e.g. <filename>postgresql.conf</>,
479
+ <literal>recovery.conf</>, because these will be overwritten or
480
+ removed in the next step.
480
481
</para>
481
482
</step>
482
483
@@ -507,6 +508,12 @@ rsync --archive --delete --hard-links --size-only /opt/PostgreSQL/9.5/data \
507
508
/opt/PostgreSQL/9.6/data standby.example.com:/opt/PostgreSQL
508
509
</programlisting>
509
510
511
+ You can verify what the command will do using
512
+ <application>rsync</>'s <option>--dry-run</> option. While
513
+ <application>rsync</> must be run on the primary for at least one
514
+ standby, it is possible to run <application>rsync</> on an upgraded
515
+ standby to upgrade other standbys, as long as the upgraded standby
516
+ has not been started.
510
517
</para>
511
518
512
519
<para>
0 commit comments