Re: 5.1.XX how are nodegroups grouped ? - Hartmut Holzgraefe - com.mysql.lists.cluster

2 messages in com.mysql.lists.clusterRe: 5.1.XX how are nodegroups grouped ?

From	Sent On	Attachments
list-mysql (www.tiri.li)	18 Jan 2008 01:38	.cnf, .ini
Hartmut Holzgraefe	18 Jan 2008 06:41

Subject:	Re: 5.1.XX how are nodegroups grouped ?
From:	Hartmut Holzgraefe (hart...@mysql.com)
Date:	01/18/2008 06:41:08 AM
List:	com.mysql.lists.cluster

list-mysql (www.tiri.li) wrote:

Hello list,

I use 5.1.22-rc.

ndb_mgm -e show says

Cluster Configuration --------------------- [ndbd(NDB)] 6 node(s) id=11 @XX (Version: 5.1.22, Nodegroup: 0, Master) id=12 @XX (Version: 5.1.22, Nodegroup: 0) id=13 @XX (Version: 5.1.22, Nodegroup: 1) id=14 @XX (Version: 5.1.22, Nodegroup: 1) id=15 @XX (Version: 5.1.22, Nodegroup: 2) id=16 @XX (Version: 5.1.22, Nodegroup: 2)

How is the affinity to nodegroups performed ?

Nodes are sorted in ascending id order and then grouped, so with NoOfReplicas=2 the two lowest node ids will end up in node group 0, the next two in node group 1 etc. ...

What about the fail-safeity if a nodegroup fails completely ?

as the nodes within a node group share copies of the same data a total loss of all nodes in a node group makes this part of the data unavailable

so as soon as the last remaining node on any node group goes down the whole cluster is shut down

What about the fail-safeity if two nodegroups fail completely ?

as the cluster is shut down on the failure of one node group already this would have the same effect

In above setup, how many nodes can fail ? I think 5 nodes can fail. Is this correct ?

no, only up to 3 nodes may fail as long as they are from different node groups, and in the worst case a loss of only two nodes will already shut down the cluster if they are in the same node group

if 3 nodes fail at the same time then even when they are from different node groups the cluster may shut down as the surviving nodes can't tell whether they are the only survivors or whether a network split has happened with the other 3 nodes still alive. so to prevent unsynchronized data changes in split halves of the cluster the remaining nodes will shut down in this case unless they get ok from an extra arbitrator node (which is usually the management node) to continue operating