Re: Streaming replica refuse to do restore_command

On Tue, Aug 12, 2014 at 12:37 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com
> wrote:

> On Tue, Aug 12, 2014 at 2:10 PM, Soni M <diptatapa(at)gmail(dot)com> wrote:
> > 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.
> What is the version of Postgres you are using?
>
> Pg 9.1 on from RHEL packages

> 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:53
> > 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",,,,,,,,,""
>
> A restart point is created each time a standby server shuts down
> 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

--
Regards,

Soni Maula Harriz