3 messages in com.mysql.lists.clusterRe: Dynamic re-configuration of the n...
FromSent OnAttachments
Kenji HIROHAMA13 Mar 2008 19:34 
Matthew Montgomery14 Mar 2008 12:12 
Kenji HIROHAMA27 Mar 2008 22:59 
Subject:Re: Dynamic re-configuration of the number of Data Node, DataMemory and IndexMemory with MySQL Cluster 5.1 (no CGE)
From:Matthew Montgomery (mmon@mysql.com)
Date:03/14/2008 12:12:51 PM
List:com.mysql.lists.cluster

Hello Kenji

On Fri, 2008-03-14 at 11:34 +0900, Kenji HIROHAMA wrote:

Hello All,

Would someone point me out which page I should refer or answer the followign questions?

1. Is it possible to change the number of Data Node without shuting down MySQL Cluster?

In my understanding, it is not possible with MySQL Cluster 4.1/5.0. How about 5.1?

Unfortunately, still no. There is work towards this for later versions. ...stay tuned!

Current method is to, take a backup, shutdown the cluster, restart with new config.ini and new number of data nodes then restore the backup.

2. Is it possible to change DataMemory without shutting down MySQL Cluster?

I guess it is possible with the following procedure, but not sure.

It is safe to increase DataMemory and IndexMemory online but not to reduce it.

Lets's say; There are two boxes named server1 and server2. Single ndbd are running on each servers, and NoOfReplicas=2, DataMemory=1.5GB

First, shuting down server2 and add physical memory (then the total memory is 8GB from 2GB)

Second, change the DataMemory of ndbd on server2 to 6.5GB

Third, start ndbd on server2 and join the cluster

Fourth, shutting down and change the configuration for server1

This is the correct procedure. However, you will need to remember to restart the management node between each config change.

However, http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-ndbd-definition.html says; "It is highly recommended that DataMemory and IndexMemory be set to the same values for all nodes. "

If these values are different. A node with a smaller DataMemory or IndexMemory of a peer in its node group can fail to recover if it does not have sufficient room in memory to accommodate the rows from the larger, surviving node.