Re: Streaming replication status - Mailing list pgsql-hackers

Heikki Linnakangas wrote: <blockquote cite="mid:4B4C231E.90508@enterprisedb.com" type="cite"><pre wrap="">Greg Smith
wrote:</pre><blockquote type="cite"><pre wrap="">I don't think anybody can deploy this feature without at least some
very
basic monitoring here.  I like the basic proposal you made back in
September for adding a pg_standbys_xlog_location to replace what you
have to get from ps right now: 
<a class="moz-txt-link-freetext"
href="http://archives.postgresql.org/pgsql-hackers/2009-09/msg00889.php">http://archives.postgresql.org/pgsql-hackers/2009-09/msg00889.php</a>

That's basic, but enough that people could get by for a V1.   </pre></blockquote><pre wrap="">
It would be more straightforward to have a function in the standby to
return the current replay location. It feels more logical to poll the
standby to get the status of the standby, instead of indirectly from the
master. Besides, the master won't know how far the standby is if the
connection to the standby is broken. </pre></blockquote><br /> This is one reason I was talking in my other message
aboutgetting simple stats on how bad the archive_command backlog is, which I'd think is an easy way to inform the DBA
"thestandby isn't keeping up and disk is filling" in a way that's more database-centric than just looking at disk space
gettinggobbled.<br /><br /> I think that it's important to be able to get whatever useful information you can from both
theprimary and the standby, because most of the interesting (read:  painful) situations here are when one or the other
isdown.  The fundamental questions here are:<br /><br /> -When things are running normally, how much is the standby
laggingby?  This is needed for a baseline of good performance, by which you can detect problems before they get too
bad.<br/> -If the standby is down altogether, how can I get more information about the state of things from the
primary?<br/> -If the primary is down, how can I tell more from the standby?<br /><br /> Predicting what people are
goingto want to do when one of these bad conditions pops up is a large step ahead of where I think this discussion
shouldbe focusing on now.  You have to show how you're going to measure the badness here in the likely failure
situationsbefore you can then take action on them.  If you do the former well enough, admins will figure out how to
dealwith the latter in a way compatible with their business processes in the first version.<br />  <br /><pre
class="moz-signature"cols="72">-- 
 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
<a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a>  <a
class="moz-txt-link-abbreviated"href="http://www.2ndQuadrant.com">www.2ndQuadrant.com</a>
 
</pre>