On Sun, Aug 23, 2015 at 09:45:50AM -0500, Andy Colson wrote:
> I think we should add a step 6.5 (before step 7 Stop both servers) with something like:
>
> If you are upgrading both a primary and standby, then we need to make sure the standby is caught up.
> If you are wal shipping then on primary run: select pg_switch_xlog();
> shut down primary
> before you shut down the standby make sure it gets caught up to the primary.
>
> I don't think its 100% required for them to be exact, is it? If they are a little different then rsync has more data to xfer from primary to standby ... but it would still work. Right?
You are one of the first to use this new ability so it is good to get
your feedback. I have developed the attached applied patch to address
the problems you saw.
First, the verification has to happen earlier, before pg_upgrade is run.
I think what is happening is that a checkpoint on server shutdown is
changing the value while pg_upgrade is running, and the rename of the
controldata file is another issue, so doing it right after the primary
is shut down is the right place.
I also added a mention that rsync, not pg_upgrade, will be run on the
standbys. You can see all the results of the patch here:
http://momjian.us/pgsql_docs/pgupgrade.html
Thanks.
--
Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/doc/src/sgml/ref/pgupgrade.sgml b/doc/src/sgml/ref/pgupgrade.sgml
new file mode 100644
index ebc0d58..fcb0316
*** a/doc/src/sgml/ref/pgupgrade.sgml
--- b/doc/src/sgml/ref/pgupgrade.sgml
*************** NET STOP postgresql-9.0
*** 310,317 ****
</para>
<para>
! Streaming replication and log-shipping standby servers can remain running until
! a later step.
</para>
</step>
--- 310,330 ----
</para>
<para>
! Streaming replication and log-shipping standby servers can
! remain running until a later step.
! </para>
! </step>
!
! <step>
! <title>Verify standby servers</title>
!
! <para>
! If you are upgrading Streaming Replication and Log-Shipping standby
! servers, 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>
</step>
*************** pg_upgrade.exe
*** 404,410 ****
If you have Streaming Replication (<xref
linkend="streaming-replication">) or Log-Shipping (<xref
linkend="warm-standby">) standby servers, follow these steps to
! upgrade them (before starting any servers):
</para>
<substeps>
--- 417,425 ----
If you have Streaming Replication (<xref
linkend="streaming-replication">) or Log-Shipping (<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>
*************** pg_upgrade.exe
*** 447,464 ****
</para>
</step>
- <step>
- <title>Verify standby servers</title>
-
- <para>
- To prevent old standby servers from being modified, run
- <application>pg_controldata</> against the primary and standby
- clusters and verify that the <quote>Latest checkpoint location</>
- values match in all clusters. (This requires the standbys to be
- shut down after the primary.)
- </para>
- </step>
-
<step>
<title>Save configuration files</title>
--- 462,467 ----
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
