Re[2]: [HACKERS] Patch: add recovery_timeout option to control timeout of restore_command nonzero status code

Поиск
Список
Период
Сортировка
От Alexey Vasiliev
Тема Re[2]: [HACKERS] Patch: add recovery_timeout option to control timeout of restore_command nonzero status code
Дата
Msg-id 1415112632.667998175@f382.i.mail.ru
обсуждение исходный текст
Ответ на Re: Patch: add recovery_timeout option to control timeout of restore_command nonzero status code  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers


Tue, 4 Nov 2014 14:41:56 +0100 от Andres Freund <andres@2ndquadrant.com>:
> Hi,
>
> On 2014-11-03 14:04:00 +0300, Alexey Vasiliev wrote:
> > *  What the patch does in a short paragraph: This patch should add option recovery_timeout, which help to control
timeoutof restore_command nonzero status code. Right now default value is 5 seconds. This is useful, if I using for
restoreof wal logs some external storage (like AWS S3) and no matter what the slave database will lag behind the
master.The problem, what for each request to AWS S3 need to pay, what is why for N nodes, which try to get next wal log
each5 seconds will be bigger price, than for example each 30 seconds. Before I do this in this way: " if !
(/usr/local/bin/envdir/etc/wal-e.d/env /usr/local/bin/wal-e wal-fetch "%f" "%p"); then sleep 60; fi ". But in this case
restart/stopdatabase slower. 
>
> Without saying that the feature is unneccessary, wouldn't this better be
> solved by using streaming rep most of the time?

But we don't need streaming rep. Master database no need to know about slaves (and no need to add this little overhead
tomaster). Slaves read wal logs from S3 and the same S3 wal logs used as backups.  

--
Alexey Vasiliev

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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Let's drop two obsolete features which are bear-traps for novices
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [REVIEW] Re: Fix xpath() to return namespace definitions