Streaming replication status
in [PgSql]
|
From: Greg Smith on 11 Jan 2010 23:24 Fujii Masao wrote: > On Mon, Jan 11, 2010 at 5:36 PM, Craig Ringer > <craig(a)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? -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.com
From: Fujii Masao on 12 Jan 2010 00:13 On Tue, Jan 12, 2010 at 1:21 PM, Greg Smith <greg(a)2ndquadrant.com> wrote: > 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: > http://archives.postgresql.org/pgsql-hackers/2009-09/msg00889.php > > That's basic, but enough that people could get by for a V1. Yeah, I have no objection to add such simple capability which monitors the lag into the first release. But I guess that, in addition to that, Simon wanted the capability to collect the statistical information about replication activity (e.g., a transfer time, a write time, replay time). So I'd like to postpone it. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 12 Jan 2010 00:16 On Tue, Jan 12, 2010 at 1:24 PM, Greg Smith <greg(a)2ndquadrant.com> wrote: > 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? Agreed. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 12 Jan 2010 02:22 Greg Smith wrote: > 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: > http://archives.postgresql.org/pgsql-hackers/2009-09/msg00889.php > > That's basic, but enough that people could get by for a V1. 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. Maybe we should just change the existing pg_current_xlog_location() function to return that when recovery is in progress. It currently throws an error during hot standby. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Stefan Kaltenbrunner on 12 Jan 2010 02:24
Fujii Masao wrote: > On Tue, Jan 12, 2010 at 1:21 PM, Greg Smith <greg(a)2ndquadrant.com> wrote: >> 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: >> http://archives.postgresql.org/pgsql-hackers/2009-09/msg00889.php >> >> That's basic, but enough that people could get by for a V1. > > Yeah, I have no objection to add such simple capability which monitors > the lag into the first release. But I guess that, in addition to that, > Simon wanted the capability to collect the statistical information about > replication activity (e.g., a transfer time, a write time, replay time). > So I'd like to postpone it. yeah getting that would all be nice and handy but we have to remember that this is really our first cut at integrated replication. Being able to monitor lag is what is needed as a minimum, more advanced stuff can and will emerge once we get some actual feedback from the field. Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |