From e76b4e0ddbdb1d1214bfa2b3d212b6d62671729d Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date: Mon, 12 Apr 2010 10:01:04 +0000
Subject: [PATCH] Adjust paragraph about monitoring streaming replication, now
that we have standby_keep_segments.
---
doc/src/sgml/high-availability.sgml | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index cff0339b523..c27c1903058 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.59 2010/04/12 09:52:29 heikki Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.60 2010/04/12 10:01:04 heikki Exp $ -->
<chapter id="high-availability">
<title>High Availability, Load Balancing, and Replication</title>
@@ -827,13 +827,9 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
<sect3 id="streaming-replication-monitoring">
<title>Monitoring</title>
<para>
- The WAL files required for the standby's recovery are not deleted from
- the <filename>pg_xlog</> directory on the primary while the standby is
- connected. If the standby lags far behind the primary, many WAL files
- will accumulate in there, and can fill up the disk. It is therefore
- important to monitor the lag to ensure the health of the standby and
- to avoid disk full situations in the primary.
- You can calculate the lag by comparing the current WAL write
+ An important health indicator of streaming replication is the amount
+ of WAL records generated in the primary, but not yet applied in the
+ standby. You can calculate this lag by comparing the current WAL write
location on the primary with the last WAL location received by the
standby. They can be retrieved using
<function>pg_current_xlog_location</> on the primary and the
--
GitLab