content_image/754851.jpg content_image/754850.jpg
occurs unnecessarily, this can in turn lead to the unnecessary loss of a node group and as thus to a failure of the cluster. 

Consider a setup where there are 4 data nodes A, B, C, and D running on 2 host computers host1  and host2 , and that these data nodes make up 2 node groups, as shown in the following table: 

<img src='content_image/754851.jpg'>

Suppose the heartbeats are transmitted in the order A->B->C->D->A. In this case, the loss of the heartbeat between the hosts causes node B to declare node A dead and node C to declare node B dead. This results in loss of Node Group 0, and so the cluster fails. On the other hand, if the order of transmission is A->B->D->C->A (and all other conditions remain as previously stated), the loss of the heartbeat causes nodes A and D to be declared dead; in this case, each node group has one surviving node, and the cluster survives. 

The HeartbeatOrder  configuration parameter makes the order of heartbeat transmission user- configurable. The default value for HeartbeatOrder  is zero; allowing the default value to be used on all data nodes causes the order of heartbeat transmission to be determined by NDB . If this parameter is used, it must be set to a nonzero value (maximum 65535) for every data node in the cluster, and this value must be unique for each data node; this causes the heartbeat transmission to proceed from data node to data node in the order of their HeartbeatOrder  values from lowest to highest (and then directly from the data node having the highest HeartbeatOrder  to the data node having the lowest value, to complete the circle). The values need not be consecutive. For example, to force the heartbeat transmission order A->B->D->C->A in the scenario outlined previously, you could set the HeartbeatOrder  values as shown here: 

<img src='content_image/754850.jpg'>

To use this parameter to change the heartbeat transmission order in a running NDB Cluster, you must first set HeartbeatOrder  for each data node in the cluster in the global configuration ( config.ini ) file (or files). To cause the change to take effect, you must perform either of the following: 

•A complete shutdown and restart of the entire cluster. 

•2 rolling restarts of the cluster in succession. All nodes must be restarted in the same order in both rolling restarts . 

You can use DUMP 908  to observe the effect of this parameter in the data node logs. 

• ConnectCheckIntervalDelay 

