Re: Streaming replication status

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Streaming replication status
Дата
Msg-id 4B4AE306.3010203@postnewspapers.com.au
обсуждение исходный текст
Ответ на Re: Streaming replication status  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Streaming replication status  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
On 9/01/2010 6:20 AM, Josh Berkus wrote:
> On 1/8/10 1:16 PM, Heikki Linnakangas wrote:
>> * A standby that connects to master, initiates streaming, and then sits
>> idle without stalls recycling of old WAL files in the master. That will
>> eventually lead to a full disk in master. Do we need some kind of a
>> emergency valve on that?
>
> WARNING: I haven't thought about how this would work together with HS yes.
>
> I think this needs to be administrator-configurable.
>
> I'd suggest a GUC approach:
>
> archiving_lag_action = { ignore, shutdown, stop }
>
> "Ignore" would be the default.  Some users would rather have the master
> shut down if the slave has stopped taking segments; that's "shutdown".
> Otherwise, it's "stop" which simply stops archiving and starts recylcing
> when we reach that number of segments.

IMO "stop" would be *really* bad without some sort of administrator 
alert support (scream for help) and/or the ability to refresh the 
slave's base backup when it started responding again. We'd start seeing 
mailing list posts along the lines of "my master failed over to the 
slave, and it's missing the last 3 months of data! Help!".

Personally, I'd be uncomfortable enabling something like that without 
_both_ an admin alert _and_ the ability to refresh the slave's base 
backup without admin intervention.

It'd also be necessary to define what exactly "lag" means here, 
preferably in a way that doesn't generally need admin tuning for most 
users. Ideally there'd be separate thresholds for "scream to the admin 
for help, something's wrong" and "forced to act, slave is holding up the 
master".

--
Craig Ringer


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: xpath improvement suggestion
Следующее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Testing with concurrent sessions