In SGML, diff -c format
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Index: doc/src/sgml/backup.sgml
===================================================================
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/backup.sgml,v
retrieving revision 2.86
diff -c -r2.86 backup.sgml
*** doc/src/sgml/backup.sgml 16 Sep 2006 00:30:11 -0000 2.86
--- doc/src/sgml/backup.sgml 19 Sep 2006 09:57:43 -0000
***************
*** 666,680 ****
<programlisting>
SELECT pg_stop_backup();
</programlisting>
! This should return successfully.
</para>
</listitem>
<listitem>
<para>
! Once the WAL segment files used during the backup are archived as part
! of normal database activity, you are done. The file identified by
! <function>pg_stop_backup</>'s result is the last segment that needs
! to be archived to complete the backup.
</para>
</listitem>
</orderedlist>
--- 666,687 ----
<programlisting>
SELECT pg_stop_backup();
</programlisting>
! This should return successfully; however, the backup is not yet fully
! valid. An automatic switch to the next WAL segment occurs, so all
! WAL segment files that relate to the backup will now be marked ready for
! archiving.
</para>
</listitem>
<listitem>
<para>
! Once the WAL segment files used during the backup are archived, you are
! done. The file identified by <function>pg_stop_backup</>'s result is
! the last segment that needs to be archived to complete the backup.
! Archival of these files will happen automatically, since you have
! already configured <varname>archive_command</>. In many cases, this
! happens fairly quickly, but you are advised to monitor your archival
! system to ensure this has taken place so that you can be certain you
! have a valid backup.
</para>
</listitem>
</orderedlist>
***************
*** 701,709 ****
It is not necessary to be very concerned about the amount of time elapsed
between <function>pg_start_backup</> and the start of the actual backup,
nor between the end of the backup and <function>pg_stop_backup</>; a
! few minutes' delay won't hurt anything. You
! must however be quite sure that these operations are carried out in
! sequence and do not overlap.
</para>
<para>
--- 708,722 ----
It is not necessary to be very concerned about the amount of time elapsed
between <function>pg_start_backup</> and the start of the actual backup,
nor between the end of the backup and <function>pg_stop_backup</>; a
! few minutes' delay won't hurt anything. However, if you normally run the
! server with <varname>full_page_writes</> disabled, you may notice a drop
! in performance between <function>pg_start_backup</> and
! <function>pg_stop_backup</>. You must ensure that these backup operations
! are carried out in sequence without any possible overlap, or you will
! invalidate the backup.
! </para>
!
! <para>
</para>
<para>
***************
*** 1437,1456 ****
<title>Failover</title>
<para>
! If the Primary Server fails then the Standby Server should take begin
failover procedures.
</para>
<para>
If the Standby Server fails then no failover need take place. If the
! Standby Server can be restarted, then the recovery process can also be
! immediately restarted, taking advantage of Restartable Recovery.
</para>
<para>
If the Primary Server fails and then immediately restarts, you must have
a mechanism for informing it that it is no longer the Primary. This is
! sometimes known as STONITH (Should the Other Node In The Head), which is
necessary to avoid situations where both systems think they are the
Primary, which can lead to confusion and ultimately data loss.
</para>
--- 1450,1471 ----
<title>Failover</title>
<para>
! If the Primary Server fails then the Standby Server should begin
failover procedures.
</para>
<para>
If the Standby Server fails then no failover need take place. If the
! Standby Server can be restarted, even some time later, then the recovery
! process can also be immediately restarted, taking advantage of
! Restartable Recovery. If the Standby Server cannot be restarted, then a
! full new Standby Server should be created.
</para>
<para>
If the Primary Server fails and then immediately restarts, you must have
a mechanism for informing it that it is no longer the Primary. This is
! sometimes known as STONITH (Shoot the Other Node In The Head), which is
necessary to avoid situations where both systems think they are the
Primary, which can lead to confusion and ultimately data loss.
</para>
***************
*** 1479,1490 ****
</para>
<para>
! So, switching from Primary to Standby Server can be fast, but requires
some time to re-prepare the failover cluster. Regular switching from
Primary to Standby is encouraged, since it allows the regular downtime
! one each system required to maintain HA. This also acts as a test of the
! failover so that it definitely works when you really need it. Written
! administration procedures are advised.
</para>
</sect2>
--- 1494,1505 ----
</para>
<para>
! So, switching from Primary to Standby Server can be fast but requires
some time to re-prepare the failover cluster. Regular switching from
Primary to Standby is encouraged, since it allows the regular downtime
! that each system requires to maintain HA. This also acts as a test of the
! failover mechanism so that it definitely works when you really need it.
! Written administration procedures are advised.
</para>
</sect2>
***************
*** 1494,1501 ****
<para>
The main features for Log Shipping in this release are based around the
file-based Log Shipping described above. It is also possible to
! implement record-based Log Shipping using the pg_xlogfile_name_offset()
! function, though this requires custom development.
</para>
<para>
--- 1509,1517 ----
<para>
The main features for Log Shipping in this release are based around the
file-based Log Shipping described above. It is also possible to
! implement record-based Log Shipping using the
! pg_xlogfile_name_offset() function (see <xref linkend="functions-admin">),
! though this requires custom development.
</para>
<para>
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
