CTDB - the 'Mainz' plan for clustered Samba

simo idra at samba.org
Sun Oct 1 19:30:11 GMT 2006


On Mon, 2006-10-02 at 05:17 +1000, tridge at samba.org wrote:
> Simo,
> 
>  > Ok, but at all effects what this will mean is that the LMASTER for most
>  > of the keys will change, is this a desirable effect?
> 
> yes, it's desirable :)
> 
> See this bit:
> 
>  1) the recovery process needs to assign every node a new VNN, and
>     will choose VNNs that are different from all the VNNs currently in
>     use. This is important to ensure that none of the old VNNs remain
>     valid, so we can detect when a 'zombie' node that is
>     non-responsive during recovery starts sending messages again. When
>     such a node wakes up it will trigger a CTDB_ERR_VNN_MAP message as
>     soon as it tries to send a CTDB message.

This triggers another question I had in mind.

What happen if an unresponsive server comes up before the recovery is
finished (same question if one node goes down during recovery)?

We need to start a new recovery phase of course, but is it ok to do so
at any moment? Even during another recovery?

> It's quite important that VNNs not remain the same after a recovery.

Yes, this was perfectly clear.

> I also don't mind if the recovery takes a few seconds. It should be a
> rare event, and having to redistribute the data during a recovery is a
> small cost. Trying to optimise for the "startup" case after a recovery
> just isn't worth doing. The important thing is to make the normal
> "running" case fast.

Ok, this is what I needed to hear.

> Also remember that the total amount of records in these databases
> tends to be small. It might be a few thousand on a moderately busy
> box, but it won't be billions. That means that redistributing data on
> a fast network is trivial.

Do we have any real statistic do back this?
What will happen in the worst case scenario?

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra at samba.org
http://samba.org



More information about the samba-technical mailing list