Re: Standby problem after restore_command Implementation
| От | Adrian Klaver |
|---|---|
| Тема | Re: Standby problem after restore_command Implementation |
| Дата | |
| Msg-id | 5548CF22.5040003@aklaver.com обсуждение исходный текст |
| Ответ на | Standby problem after restore_command Implementation ("Edson F. Lidorio" <edson@openmailbox.org>) |
| Ответы |
Re: Standby problem after restore_command Implementation
|
| Список | pgsql-general |
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.klaver@aklaver.com <mailto:adrian.klaver@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.klaver@aklaver.com
В списке pgsql-general по дате отправления: