How can we tell how far behind the standby is?

On Fri, Nov 5, 2010 at 2:46 PM, Josh Berkus <josh@agliodbs.com> wrote:

I'm continuing in my efforts now to document how to deploy and manage
replication on our wiki.  One of the things a DBA needs to do is to use
pg_current_xlog_location() (and related functions) to check how far
behind the master the standby is.

However, there's some serious problems with that:

(1) comparing these numbers is quite mathematically complex -- and, for
that matter, undocumented.

(2) pg_rotate_xlog and/or archive_timeout will create a "gap" in the
xlog positions, quite a large one if it happens near the beginning of a
file.  There is no way for any monitoring on the standby to tell the
difference between a gap created by forced rotation as opposed to being
most of a file behind, until the next record shows up.  Hello, nagios
false alerts!

(3) There is no easy way to relate a difference in log positions to an
amount of time.

I'll work on some tools to make this a bit more palatable, but I
disagree with earlier assertions that we have the replication monitoring
"done".  There's still a *lot* of work to do.

I've heard the same complaint, and I agree with your concerns.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Fri, Nov 5, 2010 at 5:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:

On Fri, Nov 5, 2010 at 2:46 PM, Josh Berkus <josh@agliodbs.com> wrote:

I'm continuing in my efforts now to document how to deploy and manage
replication on our wiki.  One of the things a DBA needs to do is to use
pg_current_xlog_location() (and related functions) to check how far
behind the master the standby is.

However, there's some serious problems with that:

(1) comparing these numbers is quite mathematically complex -- and, for
that matter, undocumented.

(2) pg_rotate_xlog and/or archive_timeout will create a "gap" in the
xlog positions, quite a large one if it happens near the beginning of a
file.  There is no way for any monitoring on the standby to tell the
difference between a gap created by forced rotation as opposed to being
most of a file behind, until the next record shows up.  Hello, nagios
false alerts!

(3) There is no easy way to relate a difference in log positions to an
amount of time.

I'll work on some tools to make this a bit more palatable, but I
disagree with earlier assertions that we have the replication monitoring
"done".  There's still a *lot* of work to do.

I've heard the same complaint, and I agree with your concerns.

"All this has happened before, and all of it will happen again."

At this point pg has the equivalent of MySQL's "show slave status" in
4.0. The output of that change significantly over time:
http://dev.mysql.com/doc/refman/4.1/en/show-slave-status.html
http://dev.mysql.com/doc/refman/5.5/en/show-slave-status.html

Also of interest
http://dev.mysql.com/doc/refman/4.1/en/show-binary-logs.html

--
Rob Wultsch
wultsch@gmail.com

On 6 November 2010 05:46, Josh Berkus <josh@agliodbs.com> wrote:

I'm continuing in my efforts now to document how to deploy and manage
replication on our wiki.  One of the things a DBA needs to do is to use
pg_current_xlog_location() (and related functions) to check how far
behind the master the standby is.

However, there's some serious problems with that:

(1) comparing these numbers is quite mathematically complex -- and, for
that matter, undocumented.

Our solution to this was to strip the slash out of the numbers and
then feed them to `bc` for comparison. The shell script for our
zabbix item looks something like this:

----
#!/bin/bash
errval=-1
primary=$(psql -At -h $1 -p $2 -c "SELECT
replace(pg_current_xlog_location(), '/', '');" postgres)
standby=$(psql -At -h $3 -p $4 -c "SELECT
replace(pg_last_xlog_receive_location(), '/', '');" postgres)

if [ -n "$primary" -a -n "$standby" ]
then
echo $(echo "ibase=16; obase=10; $primary-$standby" | bc)
else
echo $errval
fi

----
I'm posting this snippet a) in the hopes that it might help others,
and b) by way of agreement with Josh's point. Requiring every user
who wants to monitor replication to set something like this up for
themselves is ... not awesome.

Cheers,
BJ

On Sat, Nov 6, 2010 at 3:46 AM, Josh Berkus <josh@agliodbs.com> wrote:

I'm continuing in my efforts now to document how to deploy and manage
replication on our wiki.  One of the things a DBA needs to do is to use
pg_current_xlog_location() (and related functions) to check how far
behind the master the standby is.

However, there's some serious problems with that:

(1) comparing these numbers is quite mathematically complex -- and, for
that matter, undocumented.

(2) pg_rotate_xlog and/or archive_timeout will create a "gap" in the
xlog positions, quite a large one if it happens near the beginning of a
file.  There is no way for any monitoring on the standby to tell the
difference between a gap created by forced rotation as opposed to being
most of a file behind, until the next record shows up.  Hello, nagios
false alerts!

(3) There is no easy way to relate a difference in log positions to an
amount of time.

The patch which I'm proposing is helpful for you?
http://archives.postgresql.org/pgsql-hackers/2010-11/msg00167.php

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--On 5. November 2010 11:46:08 -0700 Josh Berkus <josh@agliodbs.com> wrote:

I'll work on some tools to make this a bit more palatable, but I
disagree with earlier assertions that we have the replication monitoring
"done". There's still a *lot* of work to do.

While getting familiar with our SR/HS infrastructure i scripted this

<https://github.com/psoo/pg_standby_status/blob/master/pg_standby_status.pl&gt;

Not sure if it does all things right, but it helped me a lot while load
testing SR. AFAIK Magnus has a monitoring script, too, i think this one is
it:

<https://github.com/mhagander/munin-plugins/blob/master/postgres/postgres_streaming_.in&gt;

Maybe that helps, too.

--
Thanks

Bernd

The patch which I'm proposing is helpful for you?
http://archives.postgresql.org/pgsql-hackers/2010-11/msg00167.php

Depends. Is that the timestamp on the master (when it was synced), or
the timestamp on the standby (when it was replayed)? It's only helpful
if it's the former.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

On Tue, Nov 9, 2010 at 7:57 AM, Josh Berkus <josh@agliodbs.com> wrote:

The patch which I'm proposing is helpful for you?
http://archives.postgresql.org/pgsql-hackers/2010-11/msg00167.php

Depends.  Is that the timestamp on the master (when it was synced), or
the timestamp on the standby (when it was replayed)?  It's only helpful
if it's the former.

It's the former. The function which I'm proposing returns the timestamp
of the last replayed commit/abort log record. That timestamp is given
when the commit/abort log record is generated in the master.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

It's the former. The function which I'm proposing returns the timestamp
of the last replayed commit/abort log record. That timestamp is given
when the commit/abort log record is generated in the master.

That would be *extremely* helpful for all kinds of monitoring tools.
Please complete/submit this.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com