mirror of
https://github.com/postgres/postgres.git
synced 2025-04-27 22:56:53 +03:00
Make an editorial pass over the newly SGML-ified contrib documentation.
Fix lots of bad markup, bad English, bad explanations. Last ones ... whew. Man, that was tedious.
This commit is contained in:
parent
665028f60f
commit
0e88fc08d6
File diff suppressed because it is too large
Load Diff
@ -1,207 +1,199 @@
|
||||
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgstandby.sgml,v 2.4 2007/12/16 23:00:42 tgl Exp $ -->
|
||||
|
||||
<sect1 id="pgstandby">
|
||||
<title>pg_standby</title>
|
||||
|
||||
|
||||
<indexterm zone="pgstandby">
|
||||
<primary>pg_standby</primary>
|
||||
</indexterm>
|
||||
|
||||
<para>
|
||||
<literal>pg_standby</literal> allows the creation of a Warm Standby server.
|
||||
Other configuration is required as well, all of which is described in the
|
||||
main server manual.
|
||||
</para>
|
||||
<para>
|
||||
The program is designed to be a wait-for <literal>restore_command</literal>,
|
||||
required to turn a normal archive recovery into a Warm Standby. Within the
|
||||
<literal>restore_command</literal> of the <literal>recovery.conf</literal>
|
||||
you could configure <literal>pg_standby</literal> in the following way:
|
||||
</para>
|
||||
<programlisting>
|
||||
restore_command = 'pg_standby archiveDir %f %p %r'
|
||||
</programlisting>
|
||||
<para>
|
||||
which would be sufficient to define that files will be restored from
|
||||
archiveDir.
|
||||
<application>pg_standby</> supports creation of a <quote>warm standby</>
|
||||
database server. It is designed to be a production-ready program, as well
|
||||
as a customizable template should you require specific modifications.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<literal>pg_standby</literal> features include:
|
||||
<application>pg_standby</> is designed to be a waiting
|
||||
<literal>restore_command</literal>, which is needed to turn a standard
|
||||
archive recovery into a warm standby operation. Other
|
||||
configuration is required as well, all of which is described in the main
|
||||
server manual (see <xref linkend="warm-standby">).
|
||||
</para>
|
||||
|
||||
<para>
|
||||
<application>pg_standby</application> features include:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
It is written in C. So it is very portable
|
||||
and easy to install.
|
||||
Supports copy or link for restoring WAL files
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Supports copy or link from a directory (only)
|
||||
Written in C, so very portable and easy to install
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Source easy to modify, with specifically designated
|
||||
sections to modify for your own needs, allowing
|
||||
interfaces to be written for additional Backup Archive Restore
|
||||
(BAR) systems
|
||||
Easy-to-modify source code, with specifically designated
|
||||
sections to modify for your own needs
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Already tested on Linux and Windows
|
||||
Already tested on Linux and Windows
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<sect2>
|
||||
<title>Usage</title>
|
||||
|
||||
<para>
|
||||
<literal>pg_standby</literal> should be used within the
|
||||
<literal>restore_command</literal> of the <literal>recovery.conf</literal>
|
||||
file.
|
||||
</para>
|
||||
<para>
|
||||
The basic usage should be like this:
|
||||
To configure a standby
|
||||
server to use <application>pg_standby</>, put this into its
|
||||
<filename>recovery.conf</filename> configuration file:
|
||||
</para>
|
||||
<programlisting>
|
||||
restore_command = 'pg_standby archiveDir %f %p'
|
||||
restore_command = 'pg_standby <replaceable>archiveDir</> %f %p %r'
|
||||
</programlisting>
|
||||
<para>
|
||||
with the pg_standby command usage as
|
||||
</para>
|
||||
<programlisting>
|
||||
pg_standby [OPTION]... ARCHIVELOCATION NEXTWALFILE XLOGFILEPATH [RESTARTWALFILE]
|
||||
</programlisting>
|
||||
<para>
|
||||
When used within the <literal>restore_command</literal> the %f and %p macros
|
||||
will provide the actual file and path required for the restore/recovery.
|
||||
where <replaceable>archiveDir</> is the directory from which WAL segment
|
||||
files should be restored.
|
||||
</para>
|
||||
<para>
|
||||
<literal>pg_standby</literal> assumes that <literal>ARCHIVELOCATION</literal>
|
||||
is a directory accessible by the server-owning user.
|
||||
The full syntax of <application>pg_standby</>'s command line is
|
||||
</para>
|
||||
<synopsis>
|
||||
pg_standby <optional> <replaceable>option</> ... </optional> <replaceable>archivelocation</> <replaceable>nextwalfile</> <replaceable>xlogfilepath</> <optional> <replaceable>restartwalfile</> </optional>
|
||||
</synopsis>
|
||||
<para>
|
||||
When used within <literal>restore_command</literal>, the <literal>%f</> and
|
||||
<literal>%p</> macros should be specified for <replaceable>nextwalfile</>
|
||||
and <replaceable>xlogfilepath</> respectively, to provide the actual file
|
||||
and path required for the restore.
|
||||
</para>
|
||||
<para>
|
||||
If <literal>RESTARTWALFILE</literal> is specified, typically by using the
|
||||
<literal>%r</literal> option, then all files prior to this file will be
|
||||
removed from <literal>ARCHIVELOCATION</literal>. This then minimises the
|
||||
number of files that need to be held, whilst at the same time maintaining
|
||||
restart capability. This capability additionally assumes that
|
||||
<literal>ARCHIVELOCATION</literal> directory is writable.
|
||||
If <replaceable>restartwalfile</> is specified, normally by using the
|
||||
<literal>%r</literal> macro, then all WAL files logically preceding this
|
||||
file will be removed from <replaceable>archivelocation</>. This minimizes
|
||||
the number of files that need to be retained, while preserving
|
||||
crash-restart capability. Use of this parameter is appropriate if the
|
||||
<replaceable>archivelocation</> is a transient staging area for this
|
||||
particular standby server, but <emphasis>not</> when the
|
||||
<replaceable>archivelocation</> is intended as a long-term WAL archive area.
|
||||
</para>
|
||||
<para>
|
||||
<application>pg_standby</application> assumes that
|
||||
<replaceable>archivelocation</> is a directory readable by the
|
||||
server-owning user. If <replaceable>restartwalfile</> (or <literal>-k</>)
|
||||
is specified,
|
||||
the <replaceable>archivelocation</> directory must be writable too.
|
||||
</para>
|
||||
|
||||
<table>
|
||||
<title>Options</title>
|
||||
<tgroup cols="2">
|
||||
<title><application>pg_standby</> options</title>
|
||||
<tgroup cols="3">
|
||||
<thead>
|
||||
<row>
|
||||
<entry>Option</entry>
|
||||
<entry>Default</entry>
|
||||
<entry>Description</entry>
|
||||
</row>
|
||||
</thead>
|
||||
<tbody>
|
||||
<row>
|
||||
<entry>-c</entry>
|
||||
<entry> use copy/cp command to restore WAL files from archive</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>-d</entry>
|
||||
<entry>debug/logging option.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>-k numfiles</entry>
|
||||
<entry><literal>-c</></entry>
|
||||
<entry>yes</entry>
|
||||
<entry>
|
||||
<para>
|
||||
Cleanup files in the archive so that we maintain no more than this
|
||||
many files in the archive. This parameter will be silently ignored if
|
||||
<literal>RESTARTWALFILE</literal> is specified, since that
|
||||
specification method is more accurate in determining the correct
|
||||
cut-off point in archive.
|
||||
</para>
|
||||
<para>
|
||||
You should be wary against setting this number too low,
|
||||
since this may mean you cannot restart the standby. This
|
||||
is because the last restartpoint marked in the WAL files
|
||||
may be many files in the past and can vary considerably.
|
||||
This should be set to a value exceeding the number of WAL
|
||||
files that can be recovered in 2*checkpoint_timeout seconds,
|
||||
according to the value in the warm standby postgresql.conf.
|
||||
It is wholly unrelated to the setting of checkpoint_segments
|
||||
on either primary or standby.
|
||||
</para>
|
||||
<para>
|
||||
Setting <literal>numfiles</literal> to be zero will disable deletion
|
||||
of files from <literal>ARCHIVELOCATION</literal>.
|
||||
</para>
|
||||
<para>
|
||||
If in doubt, use a large value or do not set a value at all.
|
||||
</para>
|
||||
<para>
|
||||
If you specify neither <literal>RESTARTWALFILE</> nor <literal>-k</>,
|
||||
then <literal>-k 0</> will be assumed, i.e. keep all files in archive.
|
||||
</para>
|
||||
Use <literal>cp</> or <literal>copy</> command to restore WAL files
|
||||
from archive.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>-l</entry>
|
||||
<entry><literal>-d</></entry>
|
||||
<entry>no</entry>
|
||||
<entry>Print lots of debug logging output on <filename>stderr</>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>-k</> <replaceable>numfiles</></entry>
|
||||
<entry>0</entry>
|
||||
<entry>
|
||||
<para>
|
||||
use ln command to restore WAL files from archive
|
||||
WAL files will remain in archive
|
||||
</para>
|
||||
<para>
|
||||
Link is more efficient, but the default is copy to allow you to
|
||||
maintain the WAL archive for recovery purposes as well as
|
||||
high-availability. The default setting is not necessarily recommended,
|
||||
consult the main database server manual for discussion.
|
||||
</para>
|
||||
<para>
|
||||
This option uses the Windows Vista command mklink
|
||||
to provide a file-to-file symbolic link. -l will
|
||||
not work on versions of Windows prior to Vista.
|
||||
Use the -c option instead.
|
||||
see <ulink url="http://en.wikipedia.org/wiki/NTFS_symbolic_link"></ulink>
|
||||
</para>
|
||||
Remove files from <replaceable>archivelocation</replaceable> so that
|
||||
no more than this many WAL files before the current one are kept in the
|
||||
archive. Zero (the default) means not to remove any files from
|
||||
<replaceable>archivelocation</replaceable>.
|
||||
This parameter will be silently ignored if
|
||||
<replaceable>restartwalfile</replaceable> is specified, since that
|
||||
specification method is more accurate in determining the correct
|
||||
archive cut-off point.
|
||||
Use of this parameter is <emphasis>deprecated</> as of
|
||||
<productname>PostgreSQL</> 8.3; it is safer and more efficient to
|
||||
specify a <replaceable>restartwalfile</replaceable> parameter. A too
|
||||
small setting could result in removal of files that are still needed
|
||||
for a restart of the standby server, while a too large setting wastes
|
||||
archive space.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>-r maxretries</entry>
|
||||
<entry><literal>-l</></entry>
|
||||
<entry>no</entry>
|
||||
<entry>
|
||||
<para>
|
||||
the maximum number of times to retry the restore command if it
|
||||
fails. After each failure, we wait for sleeptime * num_retries
|
||||
so that the wait time increases progressively, so by default
|
||||
we will wait 5 secs, 10 secs then 15 secs before reporting
|
||||
the failure back to the database server. This will be
|
||||
interpreted as and end of recovery and the Standby will come
|
||||
up fully as a result. <literal>Default=3 Min=0</literal>
|
||||
</para>
|
||||
Use <literal>ln</> command to restore WAL files from archive.
|
||||
Link is more efficient than copy, but the default is copy since link
|
||||
will not work in all scenarios.
|
||||
On Windows, this option uses the <literal>mklink</> command
|
||||
to provide a file-to-file symbolic link. <literal>-l</> will
|
||||
not work on versions of Windows prior to Vista.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>-s sleeptime</entry>
|
||||
<entry><literal>-r</> <replaceable>maxretries</></entry>
|
||||
<entry>3</entry>
|
||||
<entry>
|
||||
the number of seconds to sleep between testing to see
|
||||
if the file to be restored is available in the archive yet.
|
||||
The default setting is not necessarily recommended,
|
||||
consult the main database server manual for discussion.
|
||||
<literal>Default=5, Min=1, Max=60</literal>
|
||||
Set the maximum number of times to retry the copy or link command if it
|
||||
fails. After each failure, we wait for <replaceable>sleeptime</> *
|
||||
<replaceable>num_retries</>
|
||||
so that the wait time increases progressively. So by default,
|
||||
we will wait 5 secs, 10 secs, then 15 secs before reporting
|
||||
the failure back to the standby server. This will be
|
||||
interpreted as end of recovery and the standby will come
|
||||
up fully as a result.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>-t triggerfile</entry>
|
||||
<entry><literal>-s</> <replaceable>sleeptime</></entry>
|
||||
<entry>5</entry>
|
||||
<entry>
|
||||
the presence of the triggerfile will cause recovery to end
|
||||
whether or not the next file is available
|
||||
It is recommended that you use a structured filename to
|
||||
Set the number of seconds (up to 60) to sleep between tests to see
|
||||
if the WAL file to be restored is available in the archive yet.
|
||||
The default setting is not necessarily recommended;
|
||||
consult <xref linkend="warm-standby"> for discussion.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><literal>-t</> <replaceable>triggerfile</></entry>
|
||||
<entry>none</entry>
|
||||
<entry>
|
||||
Specify a trigger file whose presence should cause recovery to end
|
||||
whether or not the next WAL file is available.
|
||||
It is recommended that you use a structured filename to
|
||||
avoid confusion as to which server is being triggered
|
||||
when multiple servers exist on same system.
|
||||
e.g. /tmp/pgsql.trigger.5432
|
||||
when multiple servers exist on the same system; for example
|
||||
<filename>/tmp/pgsql.trigger.5432</>.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>-w maxwaittime</entry>
|
||||
<entry><literal>-w</> <replaceable>maxwaittime</></entry>
|
||||
<entry>0</entry>
|
||||
<entry>
|
||||
the maximum number of seconds to wait for the next file,
|
||||
after which recovery will end and the Standby will come up.
|
||||
The default setting is not necessarily recommended,
|
||||
consult the main database server manual for discussion. A setting of
|
||||
zero means wait forever.
|
||||
<literal>Default=0, Min=0</literal>
|
||||
Set the maximum number of seconds to wait for the next WAL file,
|
||||
after which recovery will end and the standby will come up.
|
||||
A setting of zero (the default) means wait forever.
|
||||
The default setting is not necessarily recommended;
|
||||
consult <xref linkend="warm-standby"> for discussion.
|
||||
</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
@ -209,89 +201,129 @@ restore_command = 'pg_standby archiveDir %f %p %r'
|
||||
</table>
|
||||
<note>
|
||||
<para>
|
||||
<literal>--help</literal> is not supported since
|
||||
<literal>pg_standby</literal> is not intended for interactive use, except
|
||||
during development and testing.
|
||||
<literal>--help</literal> is not supported since
|
||||
<application>pg_standby</application> is not intended for interactive use,
|
||||
except during development and testing.
|
||||
</para>
|
||||
</note>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Supported versions</title>
|
||||
<para>
|
||||
<literal>pg_standby</literal> is designed to work with PostgreSQL 8.2 and
|
||||
and later. It is currently compatible across minor changes between the way
|
||||
8.3 and 8.2 operate.
|
||||
</para>
|
||||
<para>
|
||||
PostgreSQL 8.3 provides the <literal>%r</literal> command line substitution,
|
||||
designed to let <literal>pg_standby</literal> know the last file it needs to
|
||||
keep. If the last parameter is omitted, no error is generated, allowing
|
||||
<literal>pg_standby</literal> to function correctly with PostgreSQL 8.2
|
||||
also. With PostgreSQL 8.2, the <literal>-k</literal> option must be used if
|
||||
archive cleanup is required. This option remains available in 8.3.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Additional design notes</title>
|
||||
<para>
|
||||
The use of a move command seems like it would be a good idea, but this would
|
||||
prevent recovery from being restartable. Also, the last WAL file is always
|
||||
requested twice from the archive.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Examples</title>
|
||||
|
||||
<para>On Linux or Unix systems, you might use:</para>
|
||||
|
||||
<programlisting>
|
||||
archive_command = 'cp %p .../archive/%f'
|
||||
|
||||
restore_command = 'pg_standby -l -d -s 2 -t /tmp/pgsql.trigger.5442 .../archive %f %p %r 2>>standby.log'
|
||||
</programlisting>
|
||||
<para>
|
||||
where the archive directory is physically located on the standby server,
|
||||
so that the <literal>archive_command</> is accessing it across NFS,
|
||||
but the files are local to the standby (enabling use of <literal>ln</>).
|
||||
This will:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Example on Linux</para>
|
||||
<programlisting>
|
||||
archive_command = 'cp %p ../archive/%f'
|
||||
|
||||
restore_command = 'pg_standby -l -d -k 255 -r 2 -s 2 -w 0 -t /tmp/pgsql.trigger.5442 $PWD/../archive %f %p 2>> standby.log'
|
||||
</programlisting>
|
||||
<para>
|
||||
which will
|
||||
use the <literal>ln</> command to restore WAL files from archive
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para>use a ln command to restore WAL files from archive</para></listitem>
|
||||
<listitem><para>produce logfile output in standby.log</para></listitem>
|
||||
<listitem><para>keep the last 255 full WAL files, plus the current one</para></listitem>
|
||||
<listitem><para>sleep for 2 seconds between checks for next WAL file is full</para></listitem>
|
||||
<listitem><para>never timeout if file not found</para></listitem>
|
||||
<listitem><para>stop waiting when a trigger file called /tmp/pgsql.trigger.5442 appears</para></listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Example on Windows
|
||||
produce debugging output in <filename>standby.log</>
|
||||
</para>
|
||||
<programlisting>
|
||||
archive_command = 'copy %p ..\\archive\\%f'
|
||||
</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
Note that backslashes need to be doubled in the archive_command, but
|
||||
*not* in the restore_command, in 8.2, 8.1, 8.0 on Windows.
|
||||
sleep for 2 seconds between checks for next WAL file availability
|
||||
</para>
|
||||
<programlisting>
|
||||
restore_command = 'pg_standby -c -d -s 5 -w 0 -t C:\pgsql.trigger.5442 ..\archive %f %p 2>> standby.log'
|
||||
</programlisting>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
which will
|
||||
stop waiting only when a trigger file called
|
||||
<filename>/tmp/pgsql.trigger.5442</> appears
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
remove no-longer-needed files from the archive directory
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem><para>use a copy command to restore WAL files from archive</para></listitem>
|
||||
<listitem><para>produce logfile output in standby.log</para></listitem>
|
||||
<listitem><para>sleep for 5 seconds between checks for next WAL file is full</para></listitem>
|
||||
<listitem><para>never timeout if file not found</para></listitem>
|
||||
<listitem><para>stop waiting when a trigger file called C:\pgsql.trigger.5442 appears</para></listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>On Windows, you might use:</para>
|
||||
|
||||
<programlisting>
|
||||
archive_command = 'copy %p ...\\archive\\%f'
|
||||
|
||||
restore_command = 'pg_standby -d -s 5 -t C:\pgsql.trigger.5442 ...\archive %f %p %r 2>>standby.log'
|
||||
</programlisting>
|
||||
<para>
|
||||
Note that backslashes need to be doubled in the
|
||||
<literal>archive_command</>, but <emphasis>not</emphasis> in the
|
||||
<literal>restore_command</>. This will:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
use the <literal>copy</> command to restore WAL files from archive
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
produce debugging output in <filename>standby.log</>
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
sleep for 5 seconds between checks for next WAL file availability
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
stop waiting only when a trigger file called
|
||||
<filename>C:\pgsql.trigger.5442</> appears
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>
|
||||
remove no-longer-needed files from the archive directory
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Since the Windows example uses <literal>copy</> at both ends, either
|
||||
or both servers might be accessing the archive directory across the
|
||||
network.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
|
||||
<sect2>
|
||||
<title>Supported server versions</title>
|
||||
|
||||
<para>
|
||||
<application>pg_standby</application> is designed to work with
|
||||
<productname>PostgreSQL</> 8.2 and later.
|
||||
</para>
|
||||
<para>
|
||||
<productname>PostgreSQL</> 8.3 provides the <literal>%r</literal> macro,
|
||||
which is designed to let <application>pg_standby</application> know the
|
||||
last file it needs to keep. With <productname>PostgreSQL</> 8.2, the
|
||||
<literal>-k</literal> option must be used if archive cleanup is
|
||||
required. This option remains available in 8.3, but its use is deprecated.
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2>
|
||||
<title>Author</title>
|
||||
|
||||
<para>
|
||||
Simon Riggs
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
Loading…
x
Reference in New Issue
Block a user