On Tue, Aug 12, 2014 at 12:37 PM, Michael Paquier <michael.paquier@xxxxxxxxx> wrote:
Pg 9.1 on from RHEL packagesOn Tue, Aug 12, 2014 at 2:10 PM, Soni M <diptatapa@xxxxxxxxx> wrote:What is the version of Postgres you are using?
> This is how i set up the db :
> Slave using streaming replica.
> We configure slave to run pg_dump which usually last for about 12 hours.
> We have limited pg_xlog on slave.
> Once the pg_xlog on slave is full while pg_dump still in progress.
> after some restart point, the slave is trying to connect to primary and
> refuse to do restore_command.
> Is this an expected behaviour?
> 2014-08-11 10:15:53.298 CDT,,,29141,,53e8de29.71d5,2,,2014-08-11 10:15:53A restart point is created each time a standby server shuts down
> CDT,,0,FATAL,XX000,"could not receive data from WAL stream: FATAL:
> requested WAL segment 0000000300002ACC000000A6 has already been removed
> ",,,,,,,,,""
> 2014-08-11 10:15:58.550 CDT,,,29146,,53e8de2e.71da,1,,2014-08-11 10:15:58
> CDT,,0,LOG,00000,"streaming replication successfully connected to
> primary",,,,,,,,,""
during WAL replay. It seems that you stopped it for a too long time,
and that WAL files that this server expected to find are done because
it was out of sight for a too long time. Then, when a standby starts
and enters in recovery, it tries first to recover necessary WAL files
from the archives with restore_command and then switches to streaming
mode if it cannot find what is necessary. Are you sure that you kept
enough WAL history in your archives and that restore_command is
pointing to the right path/host?
Regards,
--
Michael
the wal files needed still on the archives and it's on the right path.
I try this and it's solved.
I moved all pg_xlog files to a bigger storage and manually copy needed wal files from archive, and restart the server and then it runs smoothly
--
Soni Maula Harriz
Regards,
