On Tue, Aug 12, 2014 at 12:37 PM, Michael Paquier <michael.paqu...@gmail.com > wrote:
> On Tue, Aug 12, 2014 at 2:10 PM, Soni M <diptat...@gmail.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
