Thread: 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

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

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