the new primary cluster.
      </para>
     </step>

     <step>
      <title>Stop standby servers</title>

      <para>
       If the standby servers are still running, stop them now using the
       above instructions.
      </para>
     </step>

     <step>
      <title>Save configuration files</title>

      <para>
       Save any configuration files from the old standbys' configuration
       directories you need to keep, e.g.,  <filename>postgresql.conf</filename>
       (and any files included by it), <filename>postgresql.auto.conf</filename>,
       <literal>pg_hba.conf</literal>, because these will be overwritten
       or removed in the next step.
      </para>
     </step>

     <step>
      <title>Run <application>rsync</application></title>

      <para>
       When using link mode, standby servers can be quickly upgraded using
       <application>rsync</application>.  To accomplish this, from a directory on
       the primary server that is above the old and new database cluster
       directories, run this on the <emphasis>primary</emphasis> for each standby
       server:

<programlisting>
rsync --archive --delete --hard-links --size-only --no-inc-recursive old_cluster new_cluster remote_dir
</programlisting>

       where <option>old_cluster</option> and <option>new_cluster</option> are relative
       to the current directory on the primary, and <option>remote_dir</option>
       is <emphasis>above</emphasis> the old and new cluster directories
       on the standby.  The directory structure under the specified
       directories on the primary and standbys must match.  Consult the
       <application>rsync</application> manual page for details on specifying the
       remote directory, e.g.,

<programlisting>
rsync --archive --delete --hard-links --size-only --no-inc-recursive /opt/PostgreSQL/12 \
      /opt/PostgreSQL/&majorversion; standby.example.com:/opt/PostgreSQL
</programlisting>

       You can verify what the command will do using
       <application>rsync</application>'s <option>--dry-run</option> option.  While
       <application>rsync</application> must be run on the primary for at least one
       standby, it is possible to run <application>rsync</application> on an upgraded
       standby to upgrade other standbys, as long as the upgraded standby
       has not been started.
      </para>

      <para>
       What this does is to record the links created by
       <application>pg_upgrade</application>'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,
       <application>rsync</application> needlessly copies files associated with
       temporary and unlogged tables because these files don't normally
       exist on standby servers.
      </para>

      <para>
       If you have tablespaces, you will need to run a similar
       <application>rsync</application> command for each tablespace directory, e.g.:

<programlisting>
rsync --archive --delete --hard-links --size-only --no-inc-recursive /vol1/pg_tblsp/PG_12_201909212 \
      /vol1/pg_tblsp/PG_&majorversion;_202307071 standby.example.com:/vol1/pg_tblsp
</programlisting>

       If you have relocated <filename>pg_wal</filename> outside the data
       directories, <application>rsync</application> must be run on those directories
       too.
      </para>
     </step>

     <step>
      <title>Configure streaming replication and log-shipping standby servers</title>

      <para>
       Configure the servers for log shipping.  (You do not need to run
       <function>pg_backup_start()</function> and <function>pg_backup_stop()</function>
       or take a file system backup as the standbys are still synchronized