From: Craig Ringer on 11 Jan 2010 03:36 On 9/01/2010 6:20 AM, Josh Berkus wrote: > On 1/8/10 1:16 PM, Heikki Linnakangas wrote: >> * A standby that connects to master, initiates streaming, and then sits >> idle without stalls recycling of old WAL files in the master. That will >> eventually lead to a full disk in master. Do we need some kind of a >> emergency valve on that? > > WARNING: I haven't thought about how this would work together with HS yes. > > I think this needs to be administrator-configurable. > > I'd suggest a GUC approach: > > archiving_lag_action = { ignore, shutdown, stop } > > "Ignore" would be the default. Some users would rather have the master > shut down if the slave has stopped taking segments; that's "shutdown". > Otherwise, it's "stop" which simply stops archiving and starts recylcing > when we reach that number of segments. IMO "stop" would be *really* bad without some sort of administrator alert support (scream for help) and/or the ability to refresh the slave's base backup when it started responding again. We'd start seeing mailing list posts along the lines of "my master failed over to the slave, and it's missing the last 3 months of data! Help!". 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. It'd also be necessary to define what exactly "lag" means here, preferably in a way that doesn't generally need admin tuning for most users. Ideally there'd be separate thresholds for "scream to the admin for help, something's wrong" and "forced to act, slave is holding up the master". -- Craig Ringer -- 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: Bruce Momjian on 11 Jan 2010 20:16 Simon Riggs wrote: > > * I don't think we should require superuser rights for replication. > > Although you see all WAL and potentially all data in the system through > > that, a standby doesn't need any write access to the master, so it would > > be good practice to create a dedicated account with limited privileges > > for replication. > > Agreed. I think we should have a predefined user, called "replication" > that has only the correct rights. I am concerned that knowledge of this new read-only replication user would have to be spread all over the backend code, which is really not something we should be doing at this stage in 8.5 development. I am also thinking such a special user might fall out of work on mandatory access control, so maybe we should just require super-user for 8.5 and revisit this for 8.6. -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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 11 Jan 2010 22:45 On Sun, Jan 10, 2010 at 8:17 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > What could happen is that the standby could slowly lag behind master. We > don't have any way of monitoring that, as yet. Setting ps display is not > enough here. I agree that the statistical information about replication activity is very useful. But I think that it's not an urgent issue. Shall we think it later? 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 11 Jan 2010 22:59 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. 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: Greg Smith on 11 Jan 2010 23:21
Fujii Masao wrote: > On Sun, Jan 10, 2010 at 8:17 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > >> What could happen is that the standby could slowly lag behind master. We >> don't have any way of monitoring that, as yet. Setting ps display is not >> enough here. >> > > I agree that the statistical information about replication activity is > very useful. But I think that it's not an urgent issue. Shall we think > it later? > 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. -- Greg Smith 2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support greg(a)2ndQuadrant.com www.2ndQuadrant.com |