1
0
mirror of https://github.com/postgres/postgres.git synced 2025-04-29 13:56:47 +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:
Tom Lane 2007-12-16 23:00:42 +00:00
parent 665028f60f
commit 0e88fc08d6
2 changed files with 1006 additions and 831 deletions

File diff suppressed because it is too large Load Diff

View File

@ -1,3 +1,5 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/pgstandby.sgml,v 2.4 2007/12/16 23:00:42 tgl Exp $ -->
<sect1 id="pgstandby"> <sect1 id="pgstandby">
<title>pg_standby</title> <title>pg_standby</title>
@ -6,45 +8,37 @@
</indexterm> </indexterm>
<para> <para>
<literal>pg_standby</literal> allows the creation of a Warm Standby server. <application>pg_standby</> supports creation of a <quote>warm standby</>
Other configuration is required as well, all of which is described in the database server. It is designed to be a production-ready program, as well
main server manual. as a customizable template should you require specific modifications.
</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.
</para> </para>
<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> </para>
<itemizedlist> <itemizedlist>
<listitem> <listitem>
<para> <para>
It is written in C. So it is very portable Supports copy or link for restoring WAL files
and easy to install.
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
Supports copy or link from a directory (only) Written in C, so very portable and easy to install
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
<para> <para>
Source easy to modify, with specifically designated Easy-to-modify source code, with specifically designated
sections to modify for your own needs, allowing sections to modify for your own needs
interfaces to be written for additional Backup Archive Restore
(BAR) systems
</para> </para>
</listitem> </listitem>
<listitem> <listitem>
@ -56,152 +50,150 @@ restore_command = 'pg_standby archiveDir %f %p %r'
<sect2> <sect2>
<title>Usage</title> <title>Usage</title>
<para> <para>
<literal>pg_standby</literal> should be used within the To configure a standby
<literal>restore_command</literal> of the <literal>recovery.conf</literal> server to use <application>pg_standby</>, put this into its
file. <filename>recovery.conf</filename> configuration file:
</para>
<para>
The basic usage should be like this:
</para> </para>
<programlisting> <programlisting>
restore_command = 'pg_standby archiveDir %f %p' restore_command = 'pg_standby <replaceable>archiveDir</> %f %p %r'
</programlisting> </programlisting>
<para> <para>
with the pg_standby command usage as where <replaceable>archiveDir</> is the directory from which WAL segment
</para> files should be restored.
<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.
</para> </para>
<para> <para>
<literal>pg_standby</literal> assumes that <literal>ARCHIVELOCATION</literal> The full syntax of <application>pg_standby</>'s command line is
is a directory accessible by the server-owning user. </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>
<para> <para>
If <literal>RESTARTWALFILE</literal> is specified, typically by using the If <replaceable>restartwalfile</> is specified, normally by using the
<literal>%r</literal> option, then all files prior to this file will be <literal>%r</literal> macro, then all WAL files logically preceding this
removed from <literal>ARCHIVELOCATION</literal>. This then minimises the file will be removed from <replaceable>archivelocation</>. This minimizes
number of files that need to be held, whilst at the same time maintaining the number of files that need to be retained, while preserving
restart capability. This capability additionally assumes that crash-restart capability. Use of this parameter is appropriate if the
<literal>ARCHIVELOCATION</literal> directory is writable. <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> </para>
<table> <table>
<title>Options</title> <title><application>pg_standby</> options</title>
<tgroup cols="2"> <tgroup cols="3">
<thead>
<row>
<entry>Option</entry>
<entry>Default</entry>
<entry>Description</entry>
</row>
</thead>
<tbody> <tbody>
<row> <row>
<entry>-c</entry> <entry><literal>-c</></entry>
<entry> use copy/cp command to restore WAL files from archive</entry> <entry>yes</entry>
</row>
<row>
<entry>-d</entry>
<entry>debug/logging option.</entry>
</row>
<row>
<entry>-k numfiles</entry>
<entry> <entry>
<para> Use <literal>cp</> or <literal>copy</> command to restore WAL files
Cleanup files in the archive so that we maintain no more than this from archive.
many files in the archive. This parameter will be silently ignored if </entry>
<literal>RESTARTWALFILE</literal> is specified, since that </row>
<row>
<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>
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 specification method is more accurate in determining the correct
cut-off point in archive. archive cut-off point.
</para> Use of this parameter is <emphasis>deprecated</> as of
<para> <productname>PostgreSQL</> 8.3; it is safer and more efficient to
You should be wary against setting this number too low, specify a <replaceable>restartwalfile</replaceable> parameter. A too
since this may mean you cannot restart the standby. This small setting could result in removal of files that are still needed
is because the last restartpoint marked in the WAL files for a restart of the standby server, while a too large setting wastes
may be many files in the past and can vary considerably. archive space.
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>
</entry> </entry>
</row> </row>
<row> <row>
<entry>-l</entry> <entry><literal>-l</></entry>
<entry>no</entry>
<entry> <entry>
<para> Use <literal>ln</> command to restore WAL files from archive.
use ln command to restore WAL files from archive Link is more efficient than copy, but the default is copy since link
WAL files will remain in archive will not work in all scenarios.
</para> On Windows, this option uses the <literal>mklink</> command
<para> to provide a file-to-file symbolic link. <literal>-l</> will
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. 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>
</entry> </entry>
</row> </row>
<row> <row>
<entry>-r maxretries</entry> <entry><literal>-r</> <replaceable>maxretries</></entry>
<entry>3</entry>
<entry> <entry>
<para> Set the maximum number of times to retry the copy or link command if it
the maximum number of times to retry the restore command if it fails. After each failure, we wait for <replaceable>sleeptime</> *
fails. After each failure, we wait for sleeptime * num_retries <replaceable>num_retries</>
so that the wait time increases progressively, so by default so that the wait time increases progressively. So by default,
we will wait 5 secs, 10 secs then 15 secs before reporting we will wait 5 secs, 10 secs, then 15 secs before reporting
the failure back to the database server. This will be the failure back to the standby server. This will be
interpreted as and end of recovery and the Standby will come interpreted as end of recovery and the standby will come
up fully as a result. <literal>Default=3 Min=0</literal> up fully as a result.
</para>
</entry> </entry>
</row> </row>
<row> <row>
<entry>-s sleeptime</entry> <entry><literal>-s</> <replaceable>sleeptime</></entry>
<entry>5</entry>
<entry> <entry>
the number of seconds to sleep between testing to see Set the number of seconds (up to 60) to sleep between tests to see
if the file to be restored is available in the archive yet. if the WAL file to be restored is available in the archive yet.
The default setting is not necessarily recommended, The default setting is not necessarily recommended;
consult the main database server manual for discussion. consult <xref linkend="warm-standby"> for discussion.
<literal>Default=5, Min=1, Max=60</literal>
</entry> </entry>
</row> </row>
<row> <row>
<entry>-t triggerfile</entry> <entry><literal>-t</> <replaceable>triggerfile</></entry>
<entry>none</entry>
<entry> <entry>
the presence of the triggerfile will cause recovery to end Specify a trigger file whose presence should cause recovery to end
whether or not the next file is available whether or not the next WAL file is available.
It is recommended that you use a structured filename to It is recommended that you use a structured filename to
avoid confusion as to which server is being triggered avoid confusion as to which server is being triggered
when multiple servers exist on same system. when multiple servers exist on the same system; for example
e.g. /tmp/pgsql.trigger.5432 <filename>/tmp/pgsql.trigger.5432</>.
</entry> </entry>
</row> </row>
<row> <row>
<entry>-w maxwaittime</entry> <entry><literal>-w</> <replaceable>maxwaittime</></entry>
<entry>0</entry>
<entry> <entry>
the maximum number of seconds to wait for the next file, Set the maximum number of seconds to wait for the next WAL file,
after which recovery will end and the Standby will come up. after which recovery will end and the standby will come up.
The default setting is not necessarily recommended, A setting of zero (the default) means wait forever.
consult the main database server manual for discussion. A setting of The default setting is not necessarily recommended;
zero means wait forever. consult <xref linkend="warm-standby"> for discussion.
<literal>Default=0, Min=0</literal>
</entry> </entry>
</row> </row>
</tbody> </tbody>
@ -210,88 +202,128 @@ restore_command = 'pg_standby archiveDir %f %p %r'
<note> <note>
<para> <para>
<literal>--help</literal> is not supported since <literal>--help</literal> is not supported since
<literal>pg_standby</literal> is not intended for interactive use, except <application>pg_standby</application> is not intended for interactive use,
during development and testing. except during development and testing.
</para> </para>
</note> </note>
</sect2> </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> <sect2>
<title>Examples</title> <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> <itemizedlist>
<listitem> <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> <para>
which will use the <literal>ln</> command to restore WAL files from archive
</para> </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>
<listitem> <listitem>
<para> <para>
Example on Windows produce debugging output in <filename>standby.log</>
</para> </para>
<programlisting> </listitem>
archive_command = 'copy %p ..\\archive\\%f' <listitem>
</programlisting>
<para> <para>
Note that backslashes need to be doubled in the archive_command, but sleep for 2 seconds between checks for next WAL file availability
*not* in the restore_command, in 8.2, 8.1, 8.0 on Windows.
</para> </para>
<programlisting> </listitem>
restore_command = 'pg_standby -c -d -s 5 -w 0 -t C:\pgsql.trigger.5442 ..\archive %f %p 2>> standby.log' <listitem>
</programlisting>
<para> <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> </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> </listitem>
</itemizedlist> </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> </sect2>
</sect1> </sect1>