Docs pretty much as posted on hackers recently.
SGML compiles cleanly...
Comments/changes welcome.
--
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.83
diff -c -r2.83 backup.sgml
*** doc/src/sgml/backup.sgml 17 Aug 2006 23:04:02 - 2.83
--- doc/src/sgml/backup.sgml 14 Sep 2006 18:11:59 -
***
*** 1187,1192
--- 1187,1498
/sect2
/sect1
+ sect1 id=warm-standby
+ titleWarm Standby Servers for High Availability/title
+
+ indexterm zone=backup
+primaryWarm Standby/primary
+ /indexterm
+
+ indexterm zone=backup
+primaryPITR Standby/primary
+ /indexterm
+
+ indexterm zone=backup
+primaryStandby Server/primary
+ /indexterm
+
+ indexterm zone=backup
+primaryLog Shipping/primary
+ /indexterm
+
+ indexterm zone=backup
+primaryWitness Server/primary
+ /indexterm
+
+ indexterm zone=backup
+primarySTONITH/primary
+ /indexterm
+
+ indexterm zone=backup
+primaryHigh Availability/primary
+ /indexterm
+
+ para
+Continuous Archiving can be used to create a High Availability (HA)
+cluster configuration with one or more Standby Servers ready to take
+over operations in the case that the Primary Server fails. This
+capability is more widely known as Warm Standby Log Shipping.
+ /para
+
+ para
+The Primary and Standby Server work together to provide this capability,
+though the servers are only loosely coupled. The Primary Server operates
+in Continuous Archiving mode, while the Standby Server operates in a
+continuous Recovery mode, reading the WAL files from the Primary. No
+changes to the database tables are required to enable this capability,
+so it offers a low administration overhead in comparison with other
+replication approaches. This configuration also has a very low
+performance impact on the Primary server.
+ /para
+
+ para
+Directly moving WAL or log records from one database server to another
+is typically described as Log Shipping. PostgreSQL implements file-based
+Log Shipping, meaning WAL records are batched one file 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
+varies according to the transaction rate of the Primary Server.
+Record-based Log Shipping is also possible with custom-developed
+procedures, discussed in a later section. Future developments are likely
+to include options for synchronous and/or integrated record-based log
+shipping.
+ /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 can be a
+small window of data loss, should the Primary Server suffer a
+catastrophic failure. The window of data loss is minimised by the use of
+the archive_timeout parameter, which can be set as low as a few seconds
+if required. A very low setting can increase the bandwidth requirements
+for file shipping.
+ /para
+
+ para
+The Standby server is not available for access, since it is continually
+performing recovery processing. Recovery performance is sufficiently
+good that the Standby will typically be only minutes away from full
+availability once it has been activated. As a result, we refer to this
+capability as a Warm Standby configuration that offers High
+Availability. Restoring a server from an archived base backup and
+rollforward can take considerably longer and so that technique only
+really offers a solution for Disaster Recovery, not HA.
+ /para
+
+ para
+Other mechanisms for High Availability replication are available, both
+commercially and as open-source software.
+ /para
+
+ para
+In general, log shipping between servers running different release
+levels will not be possible. It is the policy of the PostgreSQL Worldwide
+Development Group not to make changes to disk formats during minor release
+upgrades, so it is likely that running different minor release levels
+on Primary and Standby servers will work successfully. However, no
+formal support for that is offered and you are advised not to allow this
+to occur over long periods.
+ /para
+
+ sect2 id=warm-standby-planning
+titlePlanning/title
+
+para
+ On the Standby server all tablespaces and paths will refer to similarly
+ named mount points, so it is important to create the Primary and Standby
+ servers so that they are as similar as possible, at least from the
+ perspective of the database server.
