Re: Wal archive way behind in streaming replication

Поиск
Список
Период
Сортировка
От Andrew Krause
Тема Re: Wal archive way behind in streaming replication
Дата
Msg-id 3709F6AF-032E-4095-B0CB-DC1CE36F6B4B@breakthroughfuel.com
обсуждение исходный текст
Ответ на Fwd: Re: Wal archive way behind in streaming replication  (John Scalia <jayknowsunix@gmail.com>)
Ответы Re: Wal archive way behind in streaming replication  (John Scalia <jayknowsunix@gmail.com>)
Re: Wal archive way behind in streaming replication  (John Scalia <jayknowsunix@gmail.com>)
Список pgsql-admin
You shouldn’t have to touch the files as long as they aren’t compressed.  You may have to restart the standby instance
toget the recovery to begin though.  I’d suggest tailing your instance log and restarting the standby instance.  It
shouldshow that the logs from the gap are applying right away at startup.  


Andrew Krause




On Jun 24, 2014, at 1:19 PM, John Scalia <jayknowsunix@gmail.com> wrote:

>
> Ok, I did the copy from pg_xlog directory into the restore.conf specifieddirectory. The standby servers seem fine
withthat, however, just copying does not inform the primary that 
> the copy has happened. The archive_status directory under pg_xlog on the primary still thinks the last WAL sent was
*B7and yet it's now writing *C9. When I did the copy it was 
> only up to *C7 and nothing else has shown in the standby's directory.
>
> Now, the *.done files in archive_status are just zero length, but I'm a bit hesitant to just do a touch for the ones
Imanually copied as I don't know if this is from an in-memory 
> queue or if it Postgresql reads the contents of this regularly in order to decide what to copy.
>
> Is that safe to do?
>
> On 6/24/2014 9:56 AM, Andrew Krause wrote:
>> You can copy all of the WAL logs from your gap to the standby.  If you place them in the correct location (directory
designatedfor restore) theinstance will automatically apply them all. 
>>
>>
>> Andrew Krause
>>
>>
>>
>> On Jun 23, 2014, at 9:24 AM, John Scalia <jayknowsunix@gmail.com> wrote:
>>
>>> Came in this morning to numerous complaints from pgpool about the standby servers being behind from the primary.
Lookinginto it, no WAL files had been transferred since late Friday. All I did was restart the primaryand the WAL
archvingresumed, however, looking at the WAL files on the standby servers, this is never going to catch up. Now, I've
gotthe archive_timeout on the primary = 600 or 10 minutes and I see WAL files in pg_xlog every 10 minutes. As they show
upon the standby servers, they're also 10 minutes apart, but the primary is writing *21 and the standby's areonly up to
*10.Now, like I said prior, with there being 10 minutes (600seconds) between transfers (the same pace as the WALs are
generated)it will never catch up. Is this really the intended behavior? How would I get the additional WAL files over
tothe standbys without waiting 10 minutes to copy them one at a time? 
>>> --
>>> Jay
>>>
>>>
>>> --
>>> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
>>> To make changes to your subscription:
>>> http://www.postgresql.org/mailpref/pgsql-admin
>>
>
>
>
>
>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin



В списке pgsql-admin по дате отправления:

Предыдущее
От: John Scalia
Дата:
Сообщение: Fwd: Re: Wal archive way behind in streaming replication
Следующее
От: Terry Khatri
Дата:
Сообщение: Function to export bytea data from database to a directory