1
- <!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.40 2010/02/09 16:50:25 heikki Exp $ -->
1
+ <!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.41 2010/02/12 08:28:44 heikki Exp $ -->
2
2
3
3
<chapter id="high-availability">
4
4
<title>High Availability, Load Balancing, and Replication</title>
@@ -764,7 +764,7 @@ if (!triggered)
764
764
<para>
765
765
<productname>PostgreSQL</> includes a simple streaming replication
766
766
mechanism, which lets the standby server to stay more up-to-date than
767
- file-based replication allows. The standby connects to the primary
767
+ file-based log shipping allows. The standby connects to the primary
768
768
and the primary starts streaming WAL records from where the standby
769
769
left off, and continues streaming them as they are generated, without
770
770
waiting for the WAL file to be filled. So with streaming replication,
@@ -805,20 +805,17 @@ if (!triggered)
805
805
806
806
<listitem>
807
807
<para>
808
- Set up connections and authentication so that the standby server can
809
- successfully connect to the pseudo <literal>replication</> database of
810
- the primary server (see
811
- <xref linkend="streaming-replication-authentication">). Ensure that
812
- <xref linkend="guc-listen-addresses"> and <filename>pg_hba.conf</> are
813
- configured appropriately on the primary.
808
+ Set <xref linkend="guc-listen-addresses"> and authentication options
809
+ (see <filename>pg_hba.conf</>) so that the standby server can connect to
810
+ the pseudo <literal>replication</> database of the primary server (see
811
+ <xref linkend="streaming-replication-authentication">).
814
812
</para>
815
813
<para>
816
814
On systems that support the keepalive socket option, setting
817
815
<xref linkend="guc-tcp-keepalives-idle">,
818
816
<xref linkend="guc-tcp-keepalives-interval"> and
819
- <xref linkend="guc-tcp-keepalives-count"> helps you to find the
820
- troubles with replication (e.g., the network outage or the failure of
821
- the standby server) as soon as possible.
817
+ <xref linkend="guc-tcp-keepalives-count"> helps the master to notice
818
+ a broken connection promptly.
822
819
</para>
823
820
</listitem>
824
821
<listitem>
@@ -827,13 +824,6 @@ if (!triggered)
827
824
(see <xref linkend="guc-max-wal-senders"> for details).
828
825
</para>
829
826
</listitem>
830
- <listitem>
831
- <para>
832
- Enable WAL archiving in the primary server because we need to make a base
833
- backup of it later (see <xref linkend="guc-archive-mode"> and
834
- <xref linkend="guc-archive-command"> for details).
835
- </para>
836
- </listitem>
837
827
<listitem>
838
828
<para>
839
829
Start the <productname>PostgreSQL</> server on the primary.
@@ -850,13 +840,12 @@ if (!triggered)
850
840
</listitem>
851
841
<listitem>
852
842
<para>
853
- Set up WAL archiving, connections and authentication like the primary
854
- server, because the standby server might work as a primary server after
855
- failover. Ensure that your settings are consistent with the
856
- <emphasis>future</> environment after the primary and the standby
857
- server are interchanged by failover. If you're setting up the standby
858
- server for e.g reporting purposes, with no plans to fail over to it,
859
- configure the standby accordingly.
843
+ If you're setting up the standby server for high availability purposes,
844
+ set up WAL archiving, connections and authentication like the primary
845
+ server, because the standby server will work as a primary server after
846
+ failover. If you're setting up the standby server for e.g reporting
847
+ purposes, with no plans to fail over to it, configure the standby
848
+ accordingly.
860
849
</para>
861
850
</listitem>
862
851
<listitem>
@@ -871,12 +860,25 @@ if (!triggered)
871
860
<listitem>
872
861
<para>
873
862
Specifies whether to start the <productname>PostgreSQL</> server as
874
- a standby. If this parameter is <literal>on</>, the streaming
875
- replication is enabled and the standby server will try to connect
876
- to the primary to receive and apply WAL records continuously. The
877
- default is <literal>off</>, which allows only an archive recovery
878
- without replication. So, streaming replication requires this
879
- parameter to be explicitly set to <literal>on</>.
863
+ a standby. If this parameter is <literal>on</>, the server will
864
+ not end recovery when the end of archived WAL is reached, but
865
+ will keep trying to continue recovery using <varname>restore_command</>
866
+ and by connecting to the primary server as specified by
867
+ <varname>primary_conninfo</> setting.
868
+ </para>
869
+ </listitem>
870
+ </varlistentry>
871
+ <varlistentry>
872
+ <term><varname>restore_command</varname> (<type>string</type>)</term>
873
+ <term><varname>restore_end_command</varname> (<type>string</type>)</term>
874
+ <listitem>
875
+ <para>
876
+ In standby-mode, <varname>restore_command</> (and <varname>restore_end_command</>) is set to a
877
+ simple command or script like in PITR. pg_standby or similar tools
878
+ that wait for the next WAL file to arrive, cannot be used with
879
+ streaming replication, as the server handles retries and waiting
880
+ itself. Set <varname>restore_command</> as you would if you were
881
+ recovering using a Continuous archiving backup (see <xref linkend="backup-pitr-recovery">).
880
882
</para>
881
883
</listitem>
882
884
</varlistentry>
@@ -902,16 +904,22 @@ if (!triggered)
902
904
the password needs to be set if the primary demands password
903
905
authentication.
904
906
</para>
907
+ <para>
908
+ This setting has no effect if <varname>standby_mode</> is <literal>off</>.
909
+ </para>
905
910
</listitem>
906
911
</varlistentry>
907
912
<varlistentry id="trigger-file" xreflabel="trigger_file">
908
913
<term><varname>trigger_file</varname> (<type>string</type>)</term>
909
914
<listitem>
910
915
<para>
911
- Specifies a trigger file whose presence activates the standby.
912
- If no trigger file is specified, the standby never exits
916
+ Specifies a trigger file whose presence ends recovery in the
917
+ standby. If no trigger file is specified, the standby never exits
913
918
recovery.
914
919
</para>
920
+ <para>
921
+ This setting has no effect if <varname>standby_mode</> is <literal>off</>.
922
+ </para>
915
923
</listitem>
916
924
</varlistentry>
917
925
</variablelist>
0 commit comments