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 по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Standby problem after restore_command Implementation
Следующее
От: Melvin Davidson
Дата:
Сообщение: Re: Standby problem after restore_command Implementation