Re: Streaming replication status
От | Robert Treat |
---|---|
Тема | Re: Streaming replication status |
Дата | |
Msg-id | 201001122044.48955.xzilla@users.sourceforge.net обсуждение исходный текст |
Ответ на | Re: Streaming replication status (Greg Smith <greg@2ndquadrant.com>) |
Список | pgsql-hackers |
On Monday 11 January 2010 23:24:24 Greg Smith wrote: > Fujii Masao wrote: > > On Mon, Jan 11, 2010 at 5:36 PM, Craig Ringer > > > > <craig@postnewspapers.com.au> wrote: > >> Personally, I'd be uncomfortable enabling something like that without > >> _both_ an admin alert _and_ the ability to refresh the slave's base > >> backup without admin intervention. > > > > What feature do you specifically need as an alert? Just writing > > the warning into the logfile is enough? Or need to notify by > > using SNMP trap message? Though I'm not sure if this is a role > > of Postgres. > > It's impossible for the database to have any idea whatsoever how people > are going to want to be alerted. Provide functions to monitor things > like replication lag, like the number of segments queued up to feed to > archive_command, and let people build their own alerting mechanism for > now. They're going to do that anyway, so why waste precious time here > building someone that's unlikely to fit any but a very narrow use case? That said, emitting the information to a log file makes for a crappy way to retrieve the information. The ideal api is that I can find the information out via result of some SELECT query; view, table ,function doesn't matter, as long as I can select it out. Bonus points for being able to get information from the hot standby. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com
В списке pgsql-hackers по дате отправления: