Management Nodes

As with all three types of node, there are parameters that you should set for all nodes (and it makes sense to set these in the DEFAULT section rather than in each node's section) and some that you must set individually.

Parameters to Define for All Management Nodes (NDB_MGMD_DEFAULT)

All the following options can go under [NDB_MGM] headers in addition to the DEFAULT section. A typical cluster has only one management daemon, but it is possible to define two or more. The procedure for doing so is covered later in this section. Either way, it makes sense to define settings that apply to all management nodes if you have more than one in the DEFAULT section.


The PortNumber parameter specifies the port number on which the management server listens for configuration requests and management commands. The default, which we suggest you not change, is 1186. You can specify different ports for different management nodes, but we recommend that you do not do so. If you wanted to run multiple management nodes on one server (for example, if you had two separate clusters that shared a management server), you could create two config.ini files (in different folders) with different port numbers and data directories and start both daemons, which would not then conflict.


The LogDestination parameter specifies where the management daemon will send the cluster logs it creates. There are three options in this regard: CONSOLE, SYSLOG, and FILE.

CONSOLE outputs the log to stdout (that is, it displays it on the screen of the server, which is great for debugging when you have the screen in front of you but not so great if you have your servers "headless" in a rack elsewhere). This is easy to set:


SYSLOG sends the log to a syslog facility; you must provide a facility parameter for this, with possible values being auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6 and local7 (not every facility is necessarily supported by every operating system). Here's an example:


FILE pipes the cluster log output to a regular file on the same machine. You can also set the following three parameters:

  • filename The name of the log file. The default is ndb_<NODEID>_cluster.log (where <NODEID> is the node ID of the management node, typically 1).
  • maxsize The maximum size to which the file can grow before logging rolls over to a new file. When this occurs, the old log file is renamed by appending .x to the filename, where x is the next number not yet used with this name. The default is 1000000.
  • maxfiles The maximum number of log files. The default is 6.

The following is an example of a configuration line:


It is also possible to specify multiple log destinations by using a semicolon-delimited string:


Again, you can specify different logging levels for different management nodes, but we suggest that you do not do so.


The DataDir parameter sets the directory where output files from the management server will be placed. These files include process output files and the daemon's process ID file, and they may include cluster log files, depending on the settings of LogDestination.


The ArbitrationRank parameter is used to define which nodes can act as arbitrators. Only management nodes and SQL nodes can be arbitrators. Therefore, this configuration option works identically if it is in an [NDB_MGM] section or a [MYSQLD] section of config.ini (the only difference is the different default values of the two different types of nodes).

ArbitrationRank can take one of the following values:

  • 0 The node will never be used as an arbitrator.
  • 1 The node has high priority; that is, it will be preferred as an arbitrator over low-priority nodes.
  • 2 The node has a low priority; that is, it will not be used as an arbitrator unless there are no nodes with higher priority available.

Normally, you should configure all management servers as high-priority arbitrators by setting their ArbitrationRank parameter to 1 (the default value) and setting this parameter for all SQL nodes to 2 (also the default).

Parameters to Define for Each Management Node (NDB_MGMD)

You should specify a Hostname parameter and, if you are setting Id values for other nodes in the cluster for the sake of neatness or if you are using multiple management nodes, you should set Id as well. Other than that, there is no need to set any other parameters, as long as the compulsory ones are fixed in the DEFAULT section.

An Example of a Management Section of a config.ini File

The following is an example of a configuration with one management node:

# Listen on default port, 1186
# Log to console, syslog and also to a file
# cluster-log in /var/log/.
# Store files in /var/lib/mysql-cluster
#All management nodes should be high priority for arbitration.

# ID of 1 (standard for management node)
Id = 1
# Enter IP instead of xx.xx.xx.xx
Hostname = xx.xx.xx.xx

You can find an example using two management nodes at the end of this chapter, in the section "Using Multiple Management Nodes." Because there is only one management node in the preceding example, you have probably noticed that it would be functionally identical to ignore the DEFAULT section and just use the following:

Id = 1
Hostname = xx.xx.xx.xx

However, it is good practice to use the DEFAULT section, if possible.

MySQL Clustering
MySQL Clustering
ISBN: 0672328550
EAN: 2147483647
Year: N/A
Pages: 93 © 2008-2020.
If you may any questions please contact us: