1- <!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.86 2006/09/16 00:30:11 momjian Exp $ -->
1+ <!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.87 2006/09/19 15:18:41 neilc Exp $ -->
22
33<chapter id="backup">
44 <title>Backup and Restore</title>
@@ -614,10 +614,10 @@ archive_command = 'test ! -f .../%f && cp %p .../%f'
614614
615615 <para>
616616 Also, you can force a segment switch manually with
617- <function>pg_switch_xlog() </>,
618- if you want to ensure that a just-finished transaction is archived
619- immediately. Other utility functions related to WAL management are
620- listed in <xref linkend="functions-admin-backup-table">.
617+ <function>pg_switch_xlog</>, if you want to ensure that a
618+ just-finished transaction is archived immediately. Other utility
619+ functions related to WAL management are listed in <xref
620+ linkend="functions-admin-backup-table">.
621621 </para>
622622 </sect2>
623623
@@ -666,15 +666,22 @@ SELECT pg_start_backup('label');
666666<programlisting>
667667SELECT pg_stop_backup();
668668</programlisting>
669- This should return successfully.
669+ This should return successfully; however, the backup is not yet fully
670+ valid. An automatic switch to the next WAL segment occurs, so all
671+ WAL segment files that relate to the backup will now be marked ready for
672+ archiving.
670673 </para>
671674 </listitem>
672675 <listitem>
673676 <para>
674- Once the WAL segment files used during the backup are archived as part
675- of normal database activity, you are done. The file identified by
676- <function>pg_stop_backup</>'s result is the last segment that needs
677- to be archived to complete the backup.
677+ Once the WAL segment files used during the backup are archived, you are
678+ done. The file identified by <function>pg_stop_backup</>'s result is
679+ the last segment that needs to be archived to complete the backup.
680+ Archival of these files will happen automatically, since you have
681+ already configured <varname>archive_command</>. In many cases, this
682+ happens fairly quickly, but you are advised to monitor your archival
683+ system to ensure this has taken place so that you can be certain you
684+ have a valid backup.
678685 </para>
679686 </listitem>
680687 </orderedlist>
@@ -701,9 +708,15 @@ SELECT pg_stop_backup();
701708 It is not necessary to be very concerned about the amount of time elapsed
702709 between <function>pg_start_backup</> and the start of the actual backup,
703710 nor between the end of the backup and <function>pg_stop_backup</>; a
704- few minutes' delay won't hurt anything. You
705- must however be quite sure that these operations are carried out in
706- sequence and do not overlap.
711+ few minutes' delay won't hurt anything. However, if you normally run the
712+ server with <varname>full_page_writes</> disabled, you may notice a drop
713+ in performance between <function>pg_start_backup</> and
714+ <function>pg_stop_backup</>. You must ensure that these backup operations
715+ are carried out in sequence without any possible overlap, or you will
716+ invalidate the backup.
717+ </para>
718+
719+ <para>
707720 </para>
708721
709722 <para>
@@ -1437,20 +1450,22 @@ if (!triggered)
14371450 <title>Failover</title>
14381451
14391452 <para>
1440- If the Primary Server fails then the Standby Server shouldtake begin
1453+ If the Primary Server fails then the Standby Server should begin
14411454 failover procedures.
14421455 </para>
14431456
14441457 <para>
14451458 If the Standby Server fails then no failover need take place. If the
1446- Standby Server can be restarted, then the recovery process can also be
1447- immediately restarted, taking advantage of Restartable Recovery.
1459+ Standby Server can be restarted, even some time later, then the recovery
1460+ process can also be immediately restarted, taking advantage of
1461+ Restartable Recovery. If the Standby Server cannot be restarted, then a
1462+ full new Standby Server should be created.
14481463 </para>
14491464
14501465 <para>
14511466 If the Primary Server fails and then immediately restarts, you must have
14521467 a mechanism for informing it that it is no longer the Primary. This is
1453- sometimes known as STONITH (Should the Other Node In The Head), which is
1468+ sometimes known as STONITH (Shoot the Other Node In The Head), which is
14541469 necessary to avoid situations where both systems think they are the
14551470 Primary, which can lead to confusion and ultimately data loss.
14561471 </para>
@@ -1479,23 +1494,25 @@ if (!triggered)
14791494 </para>
14801495
14811496 <para>
1482- So, switching from Primary to Standby Server can be fast, but requires
1497+ So, switching from Primary to Standby Server can be fast but requires
14831498 some time to re-prepare the failover cluster. Regular switching from
14841499 Primary to Standby is encouraged, since it allows the regular downtime
1485- one each systemrequired to maintain HA. This also acts as a test of the
1486- failover so that it definitely works when you really need it.Written
1487- administration procedures are advised.
1500+ that each systemrequires to maintain HA. This also acts as a test of the
1501+ failovermechanism so that it definitely works when you really need it.
1502+ Written administration procedures are advised.
14881503 </para>
14891504 </sect2>
14901505
14911506 <sect2 id="warm-standby-record">
14921507 <title>Implementing Record-based Log Shipping</title>
14931508
14941509 <para>
1495- The main features for Log Shipping in this release are based around the
1496- file-based Log Shipping described above. It is also possible to
1497- implement record-based Log Shipping using the pg_xlogfile_name_offset()
1498- function, though this requires custom development.
1510+ The main features for Log Shipping in this release are based
1511+ around the file-based Log Shipping described above. It is also
1512+ possible to implement record-based Log Shipping using the
1513+ <function>pg_xlogfile_name_offset</function> function (see <xref
1514+ linkend="functions-admin">), though this requires custom
1515+ development.
14991516 </para>
15001517
15011518 <para>
