On 3/6/13 7:02 PM, Prashanth Ranjalkar wrote:
> 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/>/*
>
>
>
> On Thu, Mar 7, 2013 at 7:02 AM, CS DBA <cs_dba(at)consistentstate(dot)com
> <mailto:cs_dba(at)consistentstate(dot)com>> wrote:
>
> 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
>
>
>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin(at)postgresql(dot)org
> <mailto:pgsql-admin(at)postgresql(dot)org>)
> To make changes to your subscription:
> 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