Re: Streaming replication status - Mailing list pgsql-hackers

From Josh Berkus
Subject Re: Streaming replication status
Date
Msg-id 4B4D3876.9030604@agliodbs.com
Whole thread Raw
In response to Re: Streaming replication status  (Greg Smith <greg@2ndquadrant.com>)
Responses Re: Streaming replication status
List pgsql-hackers
> I guess the slightly more ambitious performance monitoring bits that
> Simon was suggesting may cross the line as being too late to implement
> now though (depends on how productive the people actually coding on this
> are I guess), and certainly the ideas thrown out for implementing any
> smart behavior or alerting when replication goes bad like Josh's
> "archiving_lag_action" seem based the deadline to get addressed
> now--even though I agree with the basic idea.

Well, honestly, I wasn't talking about monitoring at all.  I was talking
about the general issue of "how should the system behave when it runs
out of disk space".

For the installation for which data integrity is paramount, when
replication becomes impossible because there is no more room for logs,
then the whole system, master and slaves, should shut down.  For most
people, they'd just want the master to start ignoring the slave and
recycling logs. Presumably, the slave would notice this and shut down.

So I was talking about data integrity, not monitoring.

However, it's probably a better thing to simply expose a way to query
how much extra log data we have, in raw form (bytes or pages).  From
this, an administration script could take appropriate action.

--Josh Berkus



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: plpython3
Next
From: Josh Berkus
Date:
Subject: Re: Streaming replication status