mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Minor fixes for high availability documentation.

Browse Source 
Erik Rijkers and me
This commit is contained in:
Robert Haas 2011-03-17 15:46:44 -04:00
parent 76dbb46153
commit f94c6f9c0f
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
doc/src/sgml/high-availability.sgml
View File

@ -873,7 +873,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
might indicate that the master server is under heavy load, while
differences between <literal>sent_location</> and
<function>pg_last_xlog_receive_location</> on the standby might indicate
network delay, or that the the standby is under heavy load.
network delay, or that the standby is under heavy load.
</para>
</sect3>
@ -952,7 +952,7 @@ synchronous_replication = on
If the standby is the first matching standby, as specified in
<varname>synchronous_standby_names</> on the primary, the reply
messages from that standby will be used to wake users waiting for
confirmation the commit record has been received. These parameters
confirmation that the commit record has been received. These parameters
allow the administrator to specify which standby servers should be
synchronous standbys. Note that the configuration of synchronous
replication is mainly on the master.
@ -1002,10 +1002,10 @@ synchronous_replication = on
<para>
With synchronous replication options specified at the application level
(on the primary) we can offer sync rep for the most important changes,
without slowing down the bulk of the total workload. Application level
options are an important and practical tool for allowing the benefits of
synchronous replication for high performance applications.
(on the primary) we can offer synchronous replication for the most
important changes, without slowing down the bulk of the total workload.
Application level options are an important and practical tool for allowing
the benefits of synchronous replication for high performance applications.
</para>
<para>
@ -1060,11 +1060,12 @@ synchronous_replication = on
<para>
If you really do lose your last standby server then you should disable
<varname>synchronous_standby_names</> and restart the primary server.
<varname>synchronous_standby_names</> and reload the configuration file
on the primary server.
</para>
<para>
If the primary is isolated from remaining standby severs you should
If the primary is isolated from remaining standby servers you should
fail over to the best candidate of those other remaining standby servers.
</para>
@ -1130,7 +1131,7 @@ synchronous_replication = on
and might stay down. To return to normal operation, a standby server
must be recreated,
either on the former primary system when it comes up, or on a third,
possibly new, system. Once complete the primary and standby can be
possibly new, system. Once complete, the primary and standby can be
considered to have switched roles. Some people choose to use a third
server to provide backup for the new primary until the new standby
server is recreated,
@ -1155,8 +1156,7 @@ synchronous_replication = on
<command>pg_ctl promote</> to fail over, <varname>trigger_file</> is
not required. If you're setting up the reporting servers that are
only used to offload read-only queries from the primary, not for high
availability purposes, you don't need to exit recovery in the standby
and promote it to a master.
availability purposes, you don't need to promote it.
</para>
</sect1>