<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.56 2010/03/31 20:35:09 heikki Exp $ -->

<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.57 2010/03/31 20:41:50 heikki Exp $ -->

<chapter id="high-availability">

<title>High Availability, Load Balancing, and Replication</title>

<title>Standby Server Operation</title>

<para>

In standby mode, the servercontinously applies WAL received from the

In standby mode, the servercontinuously applies WAL received from the

master server. The standby server can read WAL from a WAL archive

(see <varname>restore_command</>) or directly from the master

over a TCP connection (streaming replication). The standby server will

Set up continuous archiving on the primary to an archive directory

accessible from the standby, as described

in <xref linkend="continuous-archiving">. The archive location should be

accessible from the standby even when the master is down,ie. it should

accessible from the standby even when the master is down,i.e. it should

reside on the standby server itself or another trusted server, not on

the master server.

</para>

<title>Alternative method for log shipping</title>

<para>

An alternative to the built-in standby modedesribed in the previous

An alternative to the built-in standby modedescribed in the previous

sections is to use a restore_command that polls the archive location.

This was the only option available in versions 8.4 and below. In this

setup, set <varname>standby_mode</> off, because you are implementing