HOT Standby - slave does not appear to be removing wal files

[CS DBA]

All;

We're doing a migration as follows:

1) we setup a HOT standby pair

2) we did an import of a db that wan backed up via pg_dump

The pg_xlog directory has > 1700 files in it, It seems that the slave is
way behind which I get since we just imported a 55GB database but the
slave is not removing it's local pg_xlog wal files.

We actually stopped the import when the slave hit 97% full for the file
system where we have it's pg_xlog directory mounted
after like 30minutes the file count in the slave's pg_xlog dir has not
changed.

Any thoughts per why the slave is not removing these files?

Thanks in advance

[Prashanth Ranjalkar]

While setting up Hot Standby, it's not a method to copy the primary
database using dump and restore it on standby using restore command as
it's a logical backup. I doubt your WAL archiving is enabled and files are
copied to archive destination that set in archive_command therefore keep
accumulating under pg_xlog directory.

For hot standby setup, archiving must be enabled and online backup (file
system level) needs to be taken for setting up Standby server and
recovery.conf need to be prepared on slave server.

Please go through
http://www.postgresql.org/docs/9.2/static/high-availability.html for more
details.
*Thanks & Regards,*
*** *
*Prashanth Ranjalkar*
*Database Consultant & Architect*
*Skype:prashanth.ranjalkar*
*www.postgresdba.net*

Post by CS DBA
All;
1) we setup a HOT standby pair
2) we did an import of a db that wan backed up via pg_dump
The pg_xlog directory has > 1700 files in it, It seems that the slave is
way behind which I get since we just imported a 55GB database but the slave
is not removing it's local pg_xlog wal files.
We actually stopped the import when the slave hit 97% full for the file
system where we have it's pg_xlog directory mounted
after like 30minutes the file count in the slave's pg_xlog dir has not
changed.
Any thoughts per why the slave is not removing these files?
Thanks in advance
--
http://www.postgresql.org/**mailpref/pgsql-admin<http://www.postgresql.org/mailpref/pgsql-admin>

[CS DBA]

Post by Prashanth Ranjalkar
While setting up Hot Standby, it's not a method to copy the primary
database using dump and restore it on standby using restore command
as it's a logical backup. I doubt your WAL archiving is enabled and
files are copied to archive destination that set in archive_command
therefore keep accumulating under pg_xlog directory.
For hot standby setup, archiving must be enabled and online backup
(file system level) needs to be taken for setting up Standby server
and recovery.conf need to be prepared on slave server.
Please go through
http://www.postgresql.org/docs/9.2/static/high-availability.htmlfor
more details.
/*Thanks & Regards,*/
//**
/*Prashanth Ranjalkar*/
/*Database Consultant & Architect*/
/*Skype:prashanth.ranjalkar*/
*/www.postgresdba.net <http://www.postgresdba.net/>/*
All;
1) we setup a HOT standby pair
2) we did an import of a db that wan backed up via pg_dump
The pg_xlog directory has > 1700 files in it, It seems that the
slave is way behind which I get since we just imported a 55GB
database but the slave is not removing it's local pg_xlog wal files.
We actually stopped the import when the slave hit 97% full for
the file system where we have it's pg_xlog directory mounted
after like 30minutes the file count in the slave's pg_xlog dir has
not changed.
Any thoughts per why the slave is not removing these files?
Thanks in advance
--
http://www.postgresql.org/mailpref/pgsql-admin

We actually are in HOT standby mode, and it is working. However we are
also migrating a second db from an older (8.4) server into this master
so we did a dump (using the 9.2.2 pg_dump binary) from the 8.4 db and
then restored it into our current 9.2 master

[Eduardo Morras]

On Wed, 06 Mar 2013 19:09:43 -0700

Post by CS DBA
We actually are in HOT standby mode, and it is working. However we are
also migrating a second db from an older (8.4) server into this master
so we did a dump (using the 9.2.2 pg_dump binary) from the 8.4 db and
then restored it into our current 9.2 master

I don't know, but maybe the dump from 8.4 to your master is one big transaction that must be rolled by the slave. So the slave must store all wal files to be able to undo the big dump transaction.

--- ---
Eduardo Morras <***@yahoo.es>