It's possible you have wal_keep_segments set too low. What happens is that the master will keep the wals ( in your case 20) after processing them, before sending them off to the great black hole in the network (deleting) and making them unavailable to the standby. Try increasing wal_keep_segments = 100.
On Tue, May 5, 2015 at 10:09 AM, Adrian Klaver <adrian.kla...@aklaver.com> wrote: > On 05/05/2015 07:05 AM, Edson F. Lidorio wrote: > > CCing list. > > Em 2015-05-05 10:45, Adrian Klaver escreveu: >> >> On 05/03/2015 05:57 PM, Edson F. Lidorio wrote: >>> >>>> Hello, I'm having trouble on Standby after the implementation of the >>>> restore_command. I performed all the settings and it worked normally >>>> and after restart the slave server, started to generate errors in the >>>> log of the slave: >>>> >>> So is that implying that you had the standby running without the >>> restore_command? >>> >>>> I'm using Debian 8 with PostgreSQL 9.4.1 on x86_64-unknown-linux-gnu, >>>> compiled by gcc-4.9. real (Debian 4.9.2-10) 4.9.2, 64-bit Slave error >>>> log: 5/3/2015 16:46:01 BRT [10210-1] @ Replicator [unknown] error: >>>> WAL segment requested 00000001000000000000002C has been removed >>>> 5/3/2015 16:46:05 BRT [10211-1] @ Replicator [unknown] error: WAL >>>> segment requested 00000001000000000000002C has been removed 5/3/2015 >>>> 16:46:10 BRT [10214-1] @ Replicator [unknown] error: WAL segment >>>> requested 00000001000000000000002C has been removed 5/3/2015 16:46:15 >>>> BRT [10216-1] @ Replicator [unknown] error: WAL segment requested >>>> 00000001000000000000002C has been removed Master error log 5/3/2015 >>>> 19:13:35 BRT [3339-1] @ Replicator [unknown] error: WAL segment >>>> requested 00000001000000000000002C has been removed 5/3/2015 19:13:40 >>>> BRT [3341-1] @ Replicator [unknown] error: WAL segment requested >>>> 00000001000000000000002C has been removed 5/3/2015 19:13:44 BRT >>>> [3343-1] @ Replicator [unknown] error: WAL segment requested >>>> 00000001000000000000002C has been removed Settings files are as >>>> follows: master postgresql.conf listen_addresses = '*' wal_level = >>>> hot_standby archive_mode = on archive_command = 'cp "%p" >>>> /mnt/server/archivedir/"%f"' max_wal_senders = 2 wal_keep_segments = >>>> 20 pg_hba.conf host replication replicador 192.168.0.112/32 trust >>>> secondary postgresql.conf listen_addresses = '*' hot_standby = on >>>> pg_hba.conf host all all 0.0.0.0/0 md5 recover.conf em >>>> (/var/lib/postgresql/9.4/main) standby_mode=on >>>> primary_conninfo='host=192.168.0.100 user=replicador >>>> application_name= jessie-stby' trigger_file='/tmp/pgtrigger' >>>> restore_command = 'cp /mnt/server/archivedir/%f %p' >>>> archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r' >>>> >>> -- >>> Adrian Klaver >>> adrian.kla...@aklaver.com <mailto:adrian.kla...@aklaver.com> >>> >>> Yes, >> It was working. >> > > So what steps did you take to go from streaming only to streaming and > archiving? > > I suspect there was a gap in the stop/restart that allowed a WAL file to > get recycled before the archiving started. > > > >> >> > > -- > Adrian Klaver > adrian.kla...@aklaver.com > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- *Melvin Davidson* I reserve the right to fantasize. Whether or not you wish to share my fantasy is entirely up to you.
