On Fri, Jan 23, 2015 at 02:34:36PM -0500, Stephen Frost wrote:
> > > You'd have to replace the existing data directory on the master to do
> > > that, which pg_upgrade was designed specifically to not do, in case
> > > things went poorly.
> >
> > Why? Just rsync the new data directory onto the old directory on the
> > standbys. That's fine and simple.
>
> That still doesn't address the need to use --size-only, it would just
> mean that you don't need to use -H. If anything the -H part is the
> aspect which worries me the least about this approach.
I can now confirm that it works, just as Stephen said. I was able to
upgrade a standby cluster that contained the regression database, and
the pg_dump output was perfect.
I am attaching doc instruction that I will add to all branches as soon
as someone else confirms my results. You will need to use rsync
--itemize-changes to see the hard links being created, e.g.:
hf+++++++++ pgsql/data/base/16415/28188 => pgsql.old/data/base/16384/28188
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
diff --git a/doc/src/sgml/pgupgrade.sgml b/doc/src/sgml/pgupgrade.sgml
new file mode 100644
index e1cd260..91f40ce
*** a/doc/src/sgml/pgupgrade.sgml
--- b/doc/src/sgml/pgupgrade.sgml
*************** pg_upgrade.exe
*** 409,414 ****
--- 409,484 ----
</step>
<step>
+ <title>Upgrade any Log-Shipping Standby Servers</title>
+
+ <para>
+ If you have Log-Shipping Standby Servers (<xref
+ linkend="warm-standby">), follow these steps to upgrade them (before
+ starting any servers):
+ </para>
+
+ <procedure>
+
+ <step>
+ <title>Install the new PostgreSQL binaries on standby servers</title>
+
+ <para>
+ Make sure the new binaries and support files are installed
+ on all the standby servers. Do <emphasis>not</> run
+ <application>initdb</>. If <application>initdb</> was run, delete
+ the standby server data directories. Also, install any custom
+ shared object files on the new standbys that you installed in the
+ new master cluster.
+ </para>
+ </step>
+
+ <step>
+ <title>Run <application>rsync</></title>
+
+ <para>
+ From a directory that is above the old and new database cluster
+ directories, run this for each slave:
+
+ <programlisting>
+ rsync --archive --hard-links --size-only old_dir new_dir remote_dir
+ </programlisting>
+
+ where <option>old_dir</> and <option>new_dir</> 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 <option>remote_dir</>. <application>rsync</> will
+ be fast when <option>--link</> mode is used because it will create
+ hard links on the remote server rather than transfering user data.
+ </para>
+ </step>
+
+ <step>
+ <title>Configure log-shipping to standby servers</title>
+
+ <para>
+ 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 slaves are still sychronized
+ with the master.)
+ </para>
+ </step>
+
+ </procedure>
+
+ </step>
+
+ <step>
+ <title>Start the new server</title>
+
+ <para>
+ The new server and any <application>rsync</>'ed standby servers can
+ now be safely started.
+ </para>
+ </step>
+
+ <step>
<title>Post-Upgrade processing</title>
<para>
*************** psql --username postgres --file script.s
*** 548,562 ****
</para>
<para>
- A Log-Shipping Standby Server (<xref linkend="warm-standby">) cannot
- be upgraded because the server must allow writes. The simplest way
- is to upgrade the primary and use <command>rsync</> to rebuild the
- standbys. You can run <command>rsync</> while the primary is down,
- or as part of a base backup (<xref linkend="backup-base-backup">)
- which overwrites the old standby cluster.
- </para>
-
- <para>
If you want to use link mode and you do not want your old cluster
to be modified when the new cluster is started, make a copy of the
old cluster and upgrade that in link mode. To make a valid copy
--- 618,623 ----
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
