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@xxxxxxxxxxx http://geysirit.dk +45 31 51 60 00 On 08/04/2010, at 18.36, Kevin Grittner wrote: > Dennis Thrysøe<dth@xxxxxxxxxxx> 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 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
