Re: Streaming replication status - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Streaming replication status
Date
Msg-id 4B4AE306.3010203@postnewspapers.com.au
Whole thread Raw
In response to Re: Streaming replication status  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Streaming replication status  (Fujii Masao <masao.fujii@gmail.com>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: xpath improvement suggestion
Next
From: Martijn van Oosterhout
Date:
Subject: Re: Testing with concurrent sessions