On 10-11-25 11:45 AM, Jan Wieck wrote:
> On 11/23/2010 11:53 AM, Christopher Browne wrote:
>
> 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.
>
>

Having the events immediately events as confirmed on the master solves 
the problem of the master suffering a slow down.   This means that you 
could setup your cluster with cascaded slaves and not have to worry 
about a misbehaving cascaded slave impacting the master.  Assuming you 
can live with the failover implications.  I think this stands on its own 
as a feature idea.

Will this actually solve the problem I described?  The slave (that acts 
as the forwarder) still needs to keep all of the data in sl_log.  These 
tables will grow pretty big.  Are there any performance implications for 
this slave(the forwarder)?  The queries cleanupThread performs might be 
a bit on the expensive side but other than that I can't think of any.

That still leaves the initial copy to deal with. I've also noticed that 
so far no one has yet chimed in on this thread saying that this issue is 
actually causing pain for them in the real world.



> Jan
>