1- <!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.105 2007/10/1605:37:40 momjian Exp $ -->
1+ <!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.106 2007/10/1614:56:51 momjian Exp $ -->
22
33<chapter id="backup">
44 <title>Backup and Restore</title>
@@ -1316,10 +1316,9 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
13161316 <para>
13171317 Continuous archiving can be used to create a <firstterm>high
13181318 availability</> (HA) cluster configuration with one or more
1319- <firstterm>standby servers</> ready to take
1320- over operations if the primary server fails. This
1321- capability is widely referred to as <firstterm>warm standby</>
1322- or <firstterm>log shipping</>.
1319+ <firstterm>standby servers</> ready to take over operations if the
1320+ primary server fails. This capability is widely referred to as
1321+ <firstterm>warm standby</> or <firstterm>log shipping</>.
13231322 </para>
13241323
13251324 <para>
@@ -1337,26 +1336,26 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
13371336 Directly moving WAL or "log" records from one database server to another
13381337 is typically described as log shipping. <productname>PostgreSQL</>
13391338 implements file-based log shipping, which means that WAL records are
1340- transferred one file (WAL segment) at a time. WAL
1341- files can be shipped easily and cheaply over any distance, whether it be
1342- to an adjacent system, another system on the same site or another system
1343- on the far side of the globe. The bandwidth required for this technique
1339+ transferred one file (WAL segment) at a time. WAL files (16MB) can be
1340+ shipped easily and cheaply over any distance, whether it be to an
1341+ adjacent system, another system on the same site or another system on
1342+ the far side of the globe. The bandwidth required for this technique
13441343 varies according to the transaction rate of the primary server.
13451344 Record-based log shipping is also possible with custom-developed
13461345 procedures, as discussed in <xref linkend="warm-standby-record">.
13471346 </para>
13481347
13491348 <para>
1350- It should be noted that the log shipping is asynchronous, i.e. the
1351- WAL records are shipped after transaction commit. As a result there
1352- is a window for data loss should the primary server
1353- suffer a catastrophic failure: transactions not yet shipped will be lost.
1354- The length of the window of data loss
1355- can be limited by use of the <varname>archive_timeout</varname> parameter,
1356- which can be set aslow as a few seconds if required. However such low
1357- settings will substantially increase the bandwidth requirements for file
1358- shipping. If you need a window of less than a minute or so, it's probably
1359- better to look into record-based log shipping.
1349+ It should be noted that the log shipping is asynchronous, i.e. the WAL
1350+ records are shipped after transaction commit. As a result there is a
1351+ window for data loss should the primary server suffer a catastrophic
1352+ failure: transactions not yet shipped will be lost. The length of the
1353+ window of data loss can be limited by use of the
1354+ <varname>archive_timeout</varname> parameter, which can be set as low
1355+ as a few seconds if required. However such low settings will
1356+ substantially increase the bandwidth requirements for file shipping.
1357+ If you need a window of less than a minute or so, it's probably better
1358+ to look into record-based log shipping.
13601359 </para>
13611360
13621361 <para>
@@ -1367,7 +1366,7 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
13671366 capability as a warm standby configuration that offers high
13681367 availability. Restoring a server from an archived base backup and
13691368 rollforward will take considerably longer, so that technique only
1370- really offers a solution for disaster recovery, notHA .
1369+ really offers a solution for disaster recovery, nothigh availability .
13711370 </para>
13721371
13731372 <sect2 id="warm-standby-planning">
@@ -1416,22 +1415,20 @@ restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
14161415 </para>
14171416
14181417 <para>
1419- The magic that makes the two loosely coupled servers work together
1420- is simply a <varname>restore_command</> used on the standby that waits for
1421- the next WAL file to become available from the primary. The
1422- <varname>restore_command</> is specified in the <filename>recovery.conf</>
1423- file on the standby
1424- server. Normal recovery processing would request a file from the
1425- WAL archive, reporting failure if the file was unavailable. For
1426- standby processing it is normal for the next file to be
1427- unavailable, so we must be patient and wait for it to appear. A
1428- waiting <varname>restore_command</> can be written as a custom
1429- script that loops after polling for the existence of the next WAL
1430- file. There must also be some way to trigger failover, which
1431- should interrupt the <varname>restore_command</>, break the loop
1432- and return a file-not-found error to the standby server. This
1433- ends recovery and the standby will then come up as a normal
1434- server.
1418+ The magic that makes the two loosely coupled servers work together is
1419+ simply a <varname>restore_command</> used on the standby that waits
1420+ for the next WAL file to become available from the primary. The
1421+ <varname>restore_command</> is specified in the
1422+ <filename>recovery.conf</> file on the standby server. Normal recovery
1423+ processing would request a file from the WAL archive, reporting failure
1424+ if the file was unavailable. For standby processing it is normal for
1425+ the next file to be unavailable, so we must be patient and wait for
1426+ it to appear. A waiting <varname>restore_command</> can be written as
1427+ a custom script that loops after polling for the existence of the next
1428+ WAL file. There must also be some way to trigger failover, which should
1429+ interrupt the <varname>restore_command</>, break the loop and return
1430+ a file-not-found error to the standby server. This ends recovery and
1431+ the standby will then come up as a normal server.
14351432 </para>
14361433
14371434 <para>