Some high-availability.sgml improvements.
thanks,
Erik Rijkers
--- doc/src/sgml/high-availability.sgml.orig 2011-03-17 19:57:28.000000000 +0100
+++ doc/src/sgml/high-availability.sgml 2011-03-17 20:15:37.000000000 +0100
@@ -873,7 +873,7 @@
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 thendby is under heavy load.
</para>
</sect3>
@@ -946,13 +946,13 @@
<para>
After a commit record has been written to disk on the primary the
- WAL record is then sent to the standby. The standby sends reply
+ WAL record is sent to the standby. The standby sends reply
messages each time a new batch of WAL data is received, unless
<varname>wal_receiver_status_interval</> is set to zero on the standby.
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.
@@ -968,7 +968,7 @@
Note also that <varname>synchronous_commit</> is used when the user
specifies <varname>synchronous_replication</>, overriding even an
explicit setting of <varname>synchronous_commit</> to <literal>off</>.
- This is because we must write WAL to disk on primary before we replicate
+ This is because WAL must be written to disk on the primary before replication
to ensure the standby never gets ahead of the primary.
</para>
@@ -1002,7 +1002,7 @@
<para>
With synchronous replication options specified at the application level
- (on the primary) we can offer sync rep for the most important changes,
+ (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.
@@ -1029,7 +1029,7 @@
your last remaining sync standby. This can be achieved by naming multiple
potential synchronous standbys using <varname>synchronous_standby_names</>.
The first named standby will be used as the synchronous standby. Standbys
- listed after this will takeover the role of synchronous standby if the
+ listed after this will take over the role of synchronous standby if the
first one should fail.
</para>
@@ -1040,7 +1040,7 @@
we move to real-time <literal>STREAMING</> state.
The catch-up duration may be long immediately after the standby has
been created. If the standby is shutdown, then the catch-up period
- will increase according to the length of time the standby has been down.
+ will increase according to the length of time the standby is down.
The standby is only able to become a synchronous standby
once it has reached <literal>STREAMING</> state.
</para>
@@ -1064,15 +1064,15 @@
</para>
<para>
- If the primary is isolated from remaining standby severs you should
- failover to the best candidate of those other remaining standby servers.
+ If the primary is isolated from remaining standby servers you should
+ failover to the best candidate of the remaining standby servers.
</para>
<para>
If you need to re-create a standby server while transactions are
waiting, make sure that the commands to run pg_start_backup() and
pg_stop_backup() are run in a session with
- synchronous_replication = off, otherwise those requests will wait
+ <literal>synchronous_replication = off</>, otherwise those requests will wait
forever for the standby to appear.
</para>
@@ -1130,7 +1130,7 @@
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,
@@ -1153,7 +1153,7 @@
file with the filename and path specified by the <varname>trigger_file</>
setting in <filename>recovery.conf</>. If you're planning to use
<command>pg_ctl promote</> to fail over, <varname>trigger_file</> is
- not required. If you're setting up the reporting servers that are
+ not required. If you're setting up 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.
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
