On Tue, Aug 12, 2014 at 2:10 PM, Soni M <diptatapa@xxxxxxxxx> 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? > 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
