On Tue, Aug 12, 2014 at 2:10 PM, Soni M <diptatapa@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
