mirrors
/
postgres
mirror of https://github.com/postgres/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add doc clarifications for warm standby.

This commit is contained in:
Bruce Momjian 2007-10-16 14:56:51 +00:00
parent aad991b41b
commit 4fef90dfed
1 changed files with 33 additions and 36 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
doc/src/sgml/backup.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.105 2007/10/16 05:37:40 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.106 2007/10/16 14:56:51 momjian Exp $ -->
<chapter id="backup">
<title>Backup and Restore</title>
@ -1316,10 +1316,9 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
<para>
Continuous archiving can be used to create a <firstterm>high
availability</> (HA) cluster configuration with one or more
<firstterm>standby servers</> ready to take
over operations if the primary server fails. This
capability is widely referred to as <firstterm>warm standby</>
or <firstterm>log shipping</>.
<firstterm>standby servers</> ready to take over operations if the
primary server fails. This capability is widely referred to as
<firstterm>warm standby</> or <firstterm>log shipping</>.
</para>
<para>
@ -1337,26 +1336,26 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
Directly moving WAL or "log" records from one database server to another
is typically described as log shipping. <productname>PostgreSQL</>
implements file-based log shipping, which means that WAL records are
transferred one file (WAL segment) at a time. WAL
files can be shipped easily and cheaply over any distance, whether it be
to an adjacent system, another system on the same site or another system
on the far side of the globe. The bandwidth required for this technique
transferred one file (WAL segment) at a time. WAL files (16MB) can be
shipped easily and cheaply over any distance, whether it be to an
adjacent system, another system on the same site or another system on
the far side of the globe. The bandwidth required for this technique
varies according to the transaction rate of the primary server.
Record-based log shipping is also possible with custom-developed
procedures, as discussed in <xref linkend="warm-standby-record">.
</para>
<para>
It should be noted that the log shipping is asynchronous, i.e. the
WAL records are shipped after transaction commit. As a result there
is a window for data loss should the primary server
suffer a catastrophic failure: transactions not yet shipped will be lost.
The length of the window of data loss
can be limited by use of the <varname>archive_timeout</varname> parameter,
which can be set as low as a few seconds if required. However such low
settings will substantially increase the bandwidth requirements for file
shipping. If you need a window of less than a minute or so, it's probably
better to look into record-based log shipping.
It should be noted that the log shipping is asynchronous, i.e. the WAL
records are shipped after transaction commit. As a result there is a
window for data loss should the primary server suffer a catastrophic
failure: transactions not yet shipped will be lost. The length of the
window of data loss can be limited by use of the
<varname>archive_timeout</varname> parameter, which can be set as low
as a few seconds if required. However such low settings will
substantially increase the bandwidth requirements for file shipping.
If you need a window of less than a minute or so, it's probably better
to look into record-based log shipping.
</para>
<para>
@ -1367,7 +1366,7 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
capability as a warm standby configuration that offers high
availability. Restoring a server from an archived base backup and
rollforward will take considerably longer, so that technique only
really offers a solution for disaster recovery, not HA.
really offers a solution for disaster recovery, not high availability.
</para>
<sect2 id="warm-standby-planning">
@ -1416,22 +1415,20 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
</para>
<para>
The magic that makes the two loosely coupled servers work together
is simply a <varname>restore_command</> used on the standby that waits for
the next WAL file to become available from the primary. The
<varname>restore_command</> is specified in the <filename>recovery.conf</>
file on the standby
server. Normal recovery processing would request a file from the
WAL archive, reporting failure if the file was unavailable. For
standby processing it is normal for the next file to be
unavailable, so we must be patient and wait for it to appear. A
waiting <varname>restore_command</> can be written as a custom
script that loops after polling for the existence of the next WAL
file. There must also be some way to trigger failover, which
should interrupt the <varname>restore_command</>, break the loop
and return a file-not-found error to the standby server. This
ends recovery and the standby will then come up as a normal
server.
The magic that makes the two loosely coupled servers work together is
simply a <varname>restore_command</> used on the standby that waits
for the next WAL file to become available from the primary. The
<varname>restore_command</> is specified in the
<filename>recovery.conf</> file on the standby server. Normal recovery
processing would request a file from the WAL archive, reporting failure
if the file was unavailable. For standby processing it is normal for
the next file to be unavailable, so we must be patient and wait for
it to appear. A waiting <varname>restore_command</> can be written as
a custom script that loops after polling for the existence of the next
WAL file. There must also be some way to trigger failover, which should
interrupt the <varname>restore_command</>, break the loop and return
a file-not-found error to the standby server. This ends recovery and
the standby will then come up as a normal server.
</para>
<para>