Thu Nov 25 10:53:50 PST 2010
- Previous message: [Slony1-general] Feature Idea: improve performance when a large sl_log backlog exists
- Next message: [Slony1-general] Feature Idea: improve performance when a large sl_log backlog exists
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jan Wieck <JanWieck at Yahoo.com> writes: > On 11/23/2010 11:53 AM, Christopher Browne wrote: >> A different suggestion, that doesn't involve any changes to Slony... >> >> Initially, it might be a good idea to set up the new subscriber with >> FORWARD=no... > > I don't think it is actually the new subscriber, that is having a > problem, but rather the fact that the origin and all forwarders keep > the log and event data until every subscriber has confirmed it. Yes, that seems the root of the problem, and I don't expect it to be worthwhile to try to twist our way around it if we're not really getting at the root of it. > Let me ignore the problem of the initial COPY and catch up of the > first replica for now. Sure. That may be unsolvable, and if so, there's little point fighting it futilely. > This fully redundant log and event keeping until everyone has > confirmed everything is done so that any subscriber can be > reconfigured to use another data provider at any point in time, willy > nilly. It also keeps things simple for failover. But it does hurt in > the cases described, like taking a leaf node down for a few days. > > The cure for this would be to add configuration information so that > certain nodes will be allowed to "assume" confirmation from another > node and go ahead with their cleanup. This certainly complicates the > configuration, but I "assume" power users are fine with that. That all sounds pretty plausible, and worth adding as a possible enhancement. [mulling for a while...] So, would this suggest setting up a "shunned nodes" table, where a node would ignore the specified set of nodes for the purposes of confirmations? That sounds not *too* tough to implement. It's a bit of a footgun, notably as it enables losing more nodes at FAIL OVER time. I'll add a "shunned node" idea to the list. -- let name="cbbrowne" and tld="ca.afilias.info" in String.concat "@" [name;tld];; Christopher Browne "Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock phasers on the Heffalump, Piglet, meet me in transporter room three"
- Previous message: [Slony1-general] Feature Idea: improve performance when a large sl_log backlog exists
- Next message: [Slony1-general] Feature Idea: improve performance when a large sl_log backlog exists
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-general mailing list