On Thu, Aug 3, 2017 at 11:37:32AM +0200, Michael Paquier wrote:
> On Mon, Jul 31, 2017 at 6:13 PM, Robert Haas <robertmh...@gmail.com> wrote:
> > On Fri, Jul 28, 2017 at 10:35 AM, Andreas Joseph Krogh
> > <andr...@visena.com> wrote:
> >> I'm reading https://www.postgresql.org/docs/10/static/pgupgrade.html to try
> >> to understand how to upgrade standby-servers using pg_upgrade with pg10.
> >>
> >> The text in step 10 sais:
> >> "You will not be running pg_upgrade on the standby servers, but rather
> >> rsync", which to me sounds like rsync, in step 10-f, should be issued on
> >> the
> >> standy servers. Is this the case? If so I don't understand how the
> >> standby's
> >> data is upgraded and what "remote_dir" is. If rsync is supposed to be
> >> issued
> >> on the primary then I think it should be explicitly mentioned, and step
> >> 10-f
> >> should provide a clarer example with more detailed values for the
> >> directory-structures involved.
> >>
> >> I really think section 10 needs improvement as I'm certainly not
> >> comfortable
> >> upgrading standbys following the existing procedure.
> >
> > Yeah, I don't understand it either, and I have never been convinced
> > that there's any safe way to do it other than recloning the standbys
> > from the upgraded master.
>
> Here are my 2c on the matter. 10-f means that the upgraded node may
> have generated WAL with wal_level = minimal, which, at least it seems
> to me, that we have a risk of having inconsistent data pages if only a
> rsync is used on the old standbys. Like Robert, the flow we used in
> the products I work on is to re-create standbys from scratch after the
> upgrade using a fresh backup, with a VM cloning. An upgrade here is an
> in-place process not only linked to Postgres, so standby VMs are made
> of many services, some are being linked to Postgres. So this choice is
> mainly decided by those dependencies, still it feels safer anyway.
I have applied the attached doc patch back to 9.5 to clarify
pg_upgrade's rsync instructions and explain how it works.
Improvements?
--
Bruce Momjian <br...@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 +
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
new file mode 100644
index d444318..f8d9630
*** a/doc/src/sgml/ref/pgupgrade.sgml
--- b/doc/src/sgml/ref/pgupgrade.sgml
*************** NET STOP postgresql-&majorversion;
*** 332,338 ****
<para>
Also, if upgrading standby servers, change <varname>wal_level</>
to <literal>replica</> in the <filename>postgresql.conf</> file on
! the new master cluster.
</para>
</step>
--- 332,338 ----
<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>
*************** pg_upgrade.exe
*** 425,432 ****
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 the standby servers, but rather <application>rsync</>. Do not
! start any servers yet.
</para>
<substeps>
--- 425,432 ----
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 the standby servers, but rather <application>rsync</> on the
! primary. Do not start any servers yet.
</para>
<substeps>
*************** pg_upgrade.exe
*** 455,461 ****
<para>
Install the same custom shared object files on the new standbys
! that you installed in the new master cluster.
</para>
</step>
--- 455,461 ----
<para>
Install the same custom shared object files on the new standbys
! that you installed in the new primary cluster.
</para>
</step>
*************** pg_upgrade.exe
*** 482,506 ****
<title>Run <application>rsync</></title>
<para>
! From a directory that is above the old and new database cluster
! directories, run this for each standby:
<programlisting>
rsync --archive --delete --hard-links --size-only old_pgdata new_pgdata remote_dir
</programlisting>
where <option>old_pgdata</> and <option>new_pgdata</> are relative
! to the current directory, and <option>remote_dir</> is
! <emphasis>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
<application>rsync</> manual page for details on specifying the
remote directory, e.g. <literal>standbyhost:/opt/PostgreSQL/</>.
! <application>rsync</> will be fast when <application>pg_upgrade</>'s
! <option>--link</> mode is used because it will create hard links
! on the remote server rather than transferring user data.
! Unfortunately, <application>rsync</> needlessly copies the
! files associated with temporary and unlogged tables.
</para>
<para>
--- 482,514 ----
<title>Run <application>rsync</></title>
<para>
! From a directory on the primary server that is above the old and
! new database cluster directories, run this on the
! <emphasis>primary</> for each standby server:
<programlisting>
rsync --archive --delete --hard-links --size-only old_pgdata new_pgdata remote_dir
</programlisting>
where <option>old_pgdata</> and <option>new_pgdata</> are relative
! to the current directory on the primary, and <option>remote_dir</>
! is <emphasis>above</> the old and new cluster directories on
! the standby. The old and new relative cluster paths
! must match on the primary and standby server. Consult the
<application>rsync</> manual page for details on specifying the
remote directory, e.g. <literal>standbyhost:/opt/PostgreSQL/</>.
! </para>
!
! <para>
! What <application>rsync</> does is to copy files from the
! primary to the standby, and, if <application>pg_upgrade</>'s
! <option>--link</> mode was used, link files from the old to
! new clusters on the standby. It links the same files that
! <application>pg_upgrade</> linked in the primary old and new
! clusters. (Of course, linking speeds up <application>rsync</>.)
! Unfortunately, <application>rsync</> needlessly copies files
! associated with temporary and unlogged tables because these files
! don't normally exist on standby servers.
</para>
<para>
*************** rsync --archive --delete --hard-links --
*** 518,524 ****
Configure the servers for log shipping. (You do not need to run
<function>pg_start_backup()</> and <function>pg_stop_backup()</>
or take a file system backup as the standbys are still synchronized
! with the master.)
</para>
</step>
--- 526,532 ----
Configure the servers for log shipping. (You do not need to run
<function>pg_start_backup()</> and <function>pg_stop_backup()</>
or take a file system backup as the standbys are still synchronized
! with the primary.)
</para>
</step>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
