Обсуждение: WARM standby with pg_standby
Hi, I have a few elaborating questions in regard to setting up Warm Standby. 1) The master keeps writing WAL files even though I'm quite sure nothing is happening. This seems like a large waste of diskspace? 2) Sometimes my slave does not read and delete WAL files when in recovery mode. This will eventually fill up the disk. pg_controldata gives me: Minimum recovery ending location: 0/0 What does that mean? Is there any good ways of troubleshooting the behaviour, and finding out precisely what state the slave is in, etc.? Thanks, -- Geysir IT dth@geysirit.dk http://geysirit.dk +45 31 51 60 00
How to block access to a scheme
I have a database with multiple schemas. I need to block access to a particular scheme for doing maintenance on the structure of your tables. Does anyone know how to block access to the schema. I also need to disconnect users who are accessing the system.
Grateful.
Eduardo Reis
I have a database with multiple schemas. I need to block access to a particular scheme for doing maintenance on the structure of your tables. Does anyone know how to block access to the schema. I also need to disconnect users who are accessing the system.
Grateful.
Eduardo Reis
Eduardo Sá dos Reis<eduardoreis@pjf.mg.gov.br> wrote: > How to block access to a scheme > > I have a database with multiple schemas. I need to block access to > a particular scheme for doing maintenance on the structure of your > tables. Does anyone know how to block access to the schema. I'm not sure I exactly understand, but you can probably find something on this page that will help: http://www.postgresql.org/docs/8.4/interactive/sql-revoke.html Perhaps this?: REVOKE ALL ON SCHEMA x FROM y; > I also need to disconnect users who are accessing the system. http://www.postgresql.org/docs/8.4/interactive/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL-TABLE Before using these functions, you probably want to modify the pg_hba.conf file and signal a reload, to block new logins. -Kevin
Dennis Thrysøe<dth@geysirit.dk> wrote: > 1) The master keeps writing WAL files even though I'm quite sure > nothing is happening. This seems like a large waste of diskspace? What is your setting for archive_timeout? This limits how long before a WAL file is sent. You could extend the time, although that means that in case of a failure, you might not be as up-to-date. Another option is to use pg_clearxlogtail with gzip or use pglesslog. I haven't used pglesslog, but piping an empty WAL file through pg_clearxlogtail and gzip reduces it to about 16 kB (rather than 16 MB). > 2) Sometimes my slave does not read and delete WAL files when in > recovery mode. This will eventually fill up the disk. Sorry I can't help with that one -- we use our own scripts rather than pg_standby. Anyone else recognize this issue? > pg_controldata gives me: > > Minimum recovery ending location: 0/0 > > What does that mean? I think that only has meaning when the cluster is in archive recovery status. What does pg_controldata say the "Database cluster state" is when you see this? > Is there any good ways of troubleshooting the behaviour, and > finding out precisely what state the slave is in, etc.? We use pg_controldata and check "Database cluster state" to ensure that our warm standbys are still "in archive recovery" and we check the "Time of latest checkpoint" to ensure that its age is not much beyond our archive_timeout setting -- to ensure that the data is indeed still flowing. I believe that 9.0 will be adding some nicer ways to check such things. -Kevin
Hi again, After copying a new dump of the MASTER cluster data and starting the SLAVE with this data, I now get: Database cluster state: in production .. Minimum recovery ending location: 0/0 Still not exactly as expected, I guess. The log says things like : "cp: cannot stat `/psql_archive/00000001.history': No such file or directory" By the way, one of these lines each second! "2010-04-09 09:09:49 IST FATAL: the database system is starting up" Any help appreciated. -dennis -- Geysir IT dth@geysirit.dk http://geysirit.dk +45 31 51 60 00 On 08/04/2010, at 18.36, Kevin Grittner wrote: > Dennis Thrysøe<dth@geysirit.dk> wrote: > >> 1) The master keeps writing WAL files even though I'm quite sure >> nothing is happening. This seems like a large waste of diskspace? > > What is your setting for archive_timeout? This limits how long > before a WAL file is sent. You could extend the time, although that > means that in case of a failure, you might not be as up-to-date. > Another option is to use pg_clearxlogtail with gzip or use > pglesslog. I haven't used pglesslog, but piping an empty WAL file > through pg_clearxlogtail and gzip reduces it to about 16 kB (rather > than 16 MB). > >> 2) Sometimes my slave does not read and delete WAL files when in >> recovery mode. This will eventually fill up the disk. > > Sorry I can't help with that one -- we use our own scripts rather > than pg_standby. Anyone else recognize this issue? > >> pg_controldata gives me: >> >> Minimum recovery ending location: 0/0 >> >> What does that mean? > > I think that only has meaning when the cluster is in archive > recovery status. What does pg_controldata say the "Database cluster > state" is when you see this? > >> Is there any good ways of troubleshooting the behaviour, and >> finding out precisely what state the slave is in, etc.? > > We use pg_controldata and check "Database cluster state" to ensure > that our warm standbys are still "in archive recovery" and we check > the "Time of latest checkpoint" to ensure that its age is not much > beyond our archive_timeout setting -- to ensure that the data is > indeed still flowing. > > I believe that 9.0 will be adding some nicer ways to check such > things. > > -Kevin
On Fri, Apr 09, 2010 at 10:19:20AM +0200, Dennis Thrys?e wrote: > "cp: cannot stat `/psql_archive/00000001.history': No such file or directory" > > By the way, one of these lines each second! > > "2010-04-09 09:09:49 IST FATAL: the database system is starting up" I asked about this a few weeks ago and here was the reply. You're good: * From: Bruce Momjian <bruce@momjian.us> There is also change in 9.0: Fix longstanding gripe that we check for 0000000001.history at start of archive recovery, even when we know it is never present. so you should not see this when using >= PG 9.0.
Dennis Thrysøe<dth@geysirit.dk> wrote: > After copying a new dump of the MASTER cluster data and starting > the SLAVE with this data, I now get: > > Database cluster state: in production > .. > Minimum recovery ending location: 0/0 Somehow it completed archive recovery and switched over to production. How are you configured for triggering that? Is there some triggering file you need to delete before you try again? > "cp: cannot stat `/psql_archive/00000001.history': No such file > or directory" As already mentioned, that's just noise. Ignore that line, as long as you just see it once per startup. > By the way, one of these lines each second! > > "2010-04-09 09:09:49 IST FATAL: the database system is starting > up" Forever, or some fixed number of times? -Kevin
I need to disconnect user in my database without creating inconsistencies. What command should I use.
Grateful
Grateful
Eduardo
2010/4/12 Eduardo Sá dos Reis <eduardoreis@pjf.mg.gov.br>: > I need to disconnect user in my database without creating inconsistencies. > What command should I use. If you are using 8.4 then you can do pg_terminate_backend(pid) function. For more info read http://www.postgresql.org/docs/8.4/interactive/functions-admin.html -- Sergey Konoplev Blog: http://gray-hemp.blogspot.com / Linkedin: http://ru.linkedin.com/in/grayhemp / JID/GTalk: gray.ru@gmail.com / Skype: gray-hemp / ICQ: 29353802
On 12-Apr-2010, at 6:00 PM, Eduardo Sá dos Reis wrote:
I need to disconnect user in my database without creating inconsistencies. What command should I use.
GratefulEduardo
In PostgreSQL 8.4, you can use pg_terminate_backend() function.
Thanks & Regards,
Vibhor Kumar (PCP & OCP)
ITIL V3 Cerftified.
Mob: +91-9011042623
Web:www.EnterpriseDB.com