pg.ddx.io pgsql-admin@postgresql.org mailing list archive
help / color / mirror / Atom feedWARM standby with pg_standby
5+ messages / 3 participants
[nested] [flat]
* WARM standby with pg_standby
@ 2010-04-08 13:40 Dennis Thrysøe <dth@geysirit.dk>
2010-04-08 16:36 ` Re: WARM standby with pg_standby Kevin Grittner <Kevin.Grittner@wicourts.gov>
0 siblings, 1 reply; 5+ messages in thread
From: Dennis Thrysøe @ 2010-04-08 13:40 UTC (permalink / raw)
To: pgsql-admin
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: WARM standby with pg_standby
2010-04-08 13:40 WARM standby with pg_standby Dennis Thrysøe <dth@geysirit.dk>
@ 2010-04-08 16:36 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
2010-04-09 08:19 ` Re: WARM standby with pg_standby Dennis Thrysøe <dth@geysirit.dk>
0 siblings, 1 reply; 5+ messages in thread
From: Kevin Grittner @ 2010-04-08 16:36 UTC (permalink / raw)
To: Dennis Thrysøe <dth@geysirit.dk>; pgsql-admin
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: WARM standby with pg_standby
2010-04-08 13:40 WARM standby with pg_standby Dennis Thrysøe <dth@geysirit.dk>
2010-04-08 16:36 ` Re: WARM standby with pg_standby Kevin Grittner <Kevin.Grittner@wicourts.gov>
@ 2010-04-09 08:19 ` Dennis Thrysøe <dth@geysirit.dk>
2010-04-09 12:47 ` Re: WARM standby with pg_standby Ray Stell <stellr@cns.vt.edu>
2010-04-09 14:19 ` Re: WARM standby with pg_standby Kevin Grittner <Kevin.Grittner@wicourts.gov>
0 siblings, 2 replies; 5+ messages in thread
From: Dennis Thrysøe @ 2010-04-09 08:19 UTC (permalink / raw)
To: pgsql-admin
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: WARM standby with pg_standby
2010-04-08 13:40 WARM standby with pg_standby Dennis Thrysøe <dth@geysirit.dk>
2010-04-08 16:36 ` Re: WARM standby with pg_standby Kevin Grittner <Kevin.Grittner@wicourts.gov>
2010-04-09 08:19 ` Re: WARM standby with pg_standby Dennis Thrysøe <dth@geysirit.dk>
@ 2010-04-09 12:47 ` Ray Stell <stellr@cns.vt.edu>
1 sibling, 0 replies; 5+ messages in thread
From: Ray Stell @ 2010-04-09 12:47 UTC (permalink / raw)
To: Dennis Thrys?e <dth@geysirit.dk>; +Cc: pgsql-admin
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.
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: WARM standby with pg_standby
2010-04-08 13:40 WARM standby with pg_standby Dennis Thrysøe <dth@geysirit.dk>
2010-04-08 16:36 ` Re: WARM standby with pg_standby Kevin Grittner <Kevin.Grittner@wicourts.gov>
2010-04-09 08:19 ` Re: WARM standby with pg_standby Dennis Thrysøe <dth@geysirit.dk>
@ 2010-04-09 14:19 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
1 sibling, 0 replies; 5+ messages in thread
From: Kevin Grittner @ 2010-04-09 14:19 UTC (permalink / raw)
To: Dennis Thrysøe <dth@geysirit.dk>; pgsql-admin
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
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2010-04-09 14:19 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2010-04-08 13:40 WARM standby with pg_standby Dennis Thrysøe <dth@geysirit.dk>
2010-04-08 16:36 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
2010-04-09 08:19 ` Dennis Thrysøe <dth@geysirit.dk>
2010-04-09 12:47 ` Ray Stell <stellr@cns.vt.edu>
2010-04-09 14:19 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox