database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00
Code Activity

Add -c/--restore-target-wal to pg_rewind

Browse Source 
pg_rewind needs to copy from the source cluster to the target cluster a
set of relation blocks changed from the previous checkpoint where WAL
forked up to the end of WAL on the target.  Building this list of
relation blocks requires a range of WAL segments that may not be present
anymore on the target's pg_wal, causing pg_rewind to fail.  It is
possible to work around this issue by copying manually the WAL segments
needed but this may lead to some extra and actually useless work.

This commit introduces a new option allowing pg_rewind to use a
restore_command while doing the rewind by grabbing the parameter value
of restore_command from the target cluster configuration.  This allows
the rewind operation to be more reliable, so as only the WAL segments
needed by the rewind are restored from the archives.

In order to be able to do that, a new routine is added to src/common/ to
allow frontend tools to restore files from archives using an
already-built restore command.  This version is more simple than the
backend equivalent as there is no need to handle the non-recovery case.

Author: Alexey Kondratov
Reviewed-by: Andrey Borodin, Andres Freund, Alvaro Herrera, Alexander
Korotkov, Michael Paquier
Discussion: https://postgr.es/m/a3acff50-5a0d-9a2c-b3b2-ee36168955c1@postgrespro.ru
This commit is contained in:
Michael Paquier
2020-04-01 10:57:03 +09:00
parent 92d31085e9
commit a7e8ece41c
12 changed files with 360 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
doc/src/sgml/ref/pg_rewind.sgml
View File

@ -66,11 +66,11 @@ PostgreSQL documentation
can be found either on the target timeline, the source timeline, or their common
ancestor. In the typical failover scenario where the target cluster was
shut down soon after the divergence, this is not a problem, but if the
target cluster ran for a long time after the divergence, the old WAL
files might no longer be present. In that case, they can be manually
copied from the WAL archive to the <filename>pg_wal</filename> directory, or
fetched on startup by configuring <xref linkend="guc-primary-conninfo"/> or
<xref linkend="guc-restore-command"/>. The use of
target cluster ran for a long time after the divergence, its old WAL
files might no longer be present. In this case, you can manually copy them
from the WAL archive to the <filename>pg_wal</filename> directory, or run
<application>pg_rewind</application> with the <literal>-c</literal> option to
automatically retrieve them from the WAL archive. The use of
<application>pg_rewind</application> is not limited to failover, e.g. a standby
server can be promoted, run some write transactions, and then rewinded
to become a standby again.
@ -232,6 +232,19 @@ PostgreSQL documentation
</listitem>
</varlistentry>
<varlistentry>
<term><option>-c</option></term>
<term><option>--restore-target-wal</option></term>
<listitem>
<para>
Use <varname>restore_command</varname> defined in the target cluster
configuration to retrieve WAL files from the WAL archive if these
files are no longer available in the <filename>pg_wal</filename>
directory.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>--debug</option></term>
<listitem>
@ -318,7 +331,10 @@ GRANT EXECUTE ON function pg_catalog.pg_read_binary_file(text, bigint, bigint, b
history forked off from the target cluster. For each WAL record,
record each data block that was touched. This yields a list of all
the data blocks that were changed in the target cluster, after the
source cluster forked off.
source cluster forked off. If some of the WAL files are no longer
available, try re-running <application>pg_rewind</application> with
the <option>-c</option> option to search for the missing files in
the WAL archive.
</para>
</step>
<step>