Skip site navigation (1) Skip section navigation (2)

Re: Streaming replication status

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication status
Date: 2010-01-15 16:50:39
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Stefan Kaltenbrunner wrote:
> Greg Smith wrote:
>> The other popular request that keeps popping up here is  providing an 
>> easy way to see how backlogged the archive_command is, to make it 
>> easier to monitor for out of disk errors that might prove 
>> catastrophic to replication.
> I tend to disagree - in any reasonable production setup basic stulff 
> like disk space usage is monitored by non-application specific matters.
> While monitoring backlog might be interesting for other reasons, 
> citing disk space usage/exhaustions seems just wrong.

I was just mentioning that one use of the data, but there are others.  
Let's say that your archive_command works by copying things over to a 
NFS mount, and the mount goes down.  It could be a long time before you 
noticed this via disk space monitoring.  But if you were monitoring "how 
long has it been since the last time pg_last_archived_xlogfile() 
changed?", this would jump right out at you.

Another popular question is "how far behind real-time is the archiver 
process?"  You can do this right now by duplicating the same xlog file 
name scanning and sorting that the archiver does in your own code, 
looking for .ready files.  It would be simpler if you could call 
pg_last_archived_xlogfile() and then just grab that file's timestamp.

I think it's also important to consider the fact that diagnostic 
internals exposed via the database are far more useful to some people 
than things you have to setup outside of it.  You talk about reasonable 
configurations above, but some production setups are not so reasonable.  
In many of the more secure environments I've worked in (finance, 
defense), there is *no* access to the database server beyond what comes 
out of port 5432 without getting a whole separate team of people 
involved.  If the DBA can write a simple monitoring program themselves 
that presents data via the one port that is exposed, that makes life 
easier for them.  This same issue pops up sometimes when we consider the 
shared hosting case too, where the user may not have the option of 
running a full-fledged monitoring script.

Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support

In response to


pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2010-01-15 16:55:59
Subject: Re: Streaming replication status
Previous:From: Heikki LinnakangasDate: 2010-01-15 16:47:44
Subject: Re: Streaming replication, loose ends

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group