Documentation Home
MySQL Cluster NDB 6.1-7.1


MySQL Cluster NDB 6.1-7.1  /  ...  /  Defining a MySQL Cluster Management Server

5.3.5 Defining a MySQL Cluster Management Server

The [ndb_mgmd] section is used to configure the behavior of the management server. If multiple management servers are employed, you can specify parameters common to all of them in an [ndb_mgmd default] section. [mgm] and [mgm default] are older aliases for these, supported for backward compatibility.

All parameters in the following list are optional and assume their default values if omitted.

Note

If neither the ExecuteOnComputer nor the HostName parameter is present, the default value localhost will be assumed for both.

  • Id

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    MySQL 5.1.0unsigned[none]1 - 63IS
    NDB 6.1.1unsigned[none]1 - 255IS

    Each node in the cluster has a unique identity. For a management node, this is represented by an integer value in the range 1 to 63 inclusive (previous to MySQL Cluster NDB 6.1.1), or in the range 1 to 255 inclusive (MySQL Cluster NDB 6.1.1 and later). This ID is used by all internal cluster messages for addressing the node, and so must be unique for each MySQL Cluster node, regardless of the type of node.

    Note

    Data node IDs must be less than 49, regardless of the MySQL Cluster version used. If you plan to deploy a large number of data nodes, it is a good idea to limit the node IDs for management nodes (and API nodes) to values greater than 48.

    The use of the Id parameter for identifying management nodes is deprecated in favor of NodeId beginning with MySQL Cluster NDB 6.2.19, MySQL Cluster NDB 6.3.39, MySQL Cluster NDB 7.0.20, and MySQL Cluster NDB 7.1.9. Although Id continues to be supported for backward compatibility, it now generates a warning.

  • NodeId

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    MySQL 5.1.0unsigned[none]1 - 63IS
    NDB 6.1.1unsigned[none]1 - 255IS

    Each node in the cluster has a unique identity. For a management node, this is represented by an integer value in the range 1 to 63 inclusive (previous to MySQL Cluster NDB 6.1.1), or in the range 1 to 255 inclusive (MySQL Cluster NDB 6.1.1 and later). This ID is used by all internal cluster messages for addressing the node, and so must be unique for each MySQL Cluster node, regardless of the type of node.

    Note

    Data node IDs must be less than 49, regardless of the MySQL Cluster version used. If you plan to deploy a large number of data nodes, it is a good idea to limit the node IDs for management nodes (and API nodes) to values greater than 48.

    NodeId is the preferred parameter name to use when identifying management nodes beginning with MySQL Cluster NDB 6.2.19, MySQL Cluster NDB 6.3.39, MySQL Cluster NDB 7.0.20, and MySQL Cluster NDB 7.1.9. Although Id continues to be supported for backward compatibility, it is now deprecated and generates a warning when used.

  • ExecuteOnComputer

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    MySQL 5.1.0name[none]...S

    This refers to the Id set for one of the computers defined in a [computer] section of the config.ini file.

  • PortNumber

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    MySQL 5.1.0unsigned11860 - 64KS

    This is the port number on which the management server listens for configuration requests and management commands.

  • HostName

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    MySQL 5.1.0name or IP address[none]...N

    Specifying this parameter defines the hostname of the computer on which the management node is to reside. To specify a hostname other than localhost, either this parameter or ExecuteOnComputer is required.

  • LogDestination

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    MySQL 5.1.0{CONSOLE|SYSLOG|FILE}[see text]...N

    This parameter specifies where to send cluster logging information. There are three options in this regard—CONSOLE, SYSLOG, and FILE—with FILE being the default:

    • CONSOLE outputs the log to stdout:

      CONSOLE
      
    • SYSLOG sends the log to a syslog facility, possible values being one of auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, or local7.

      Note

      Not every facility is necessarily supported by every operating system.

      SYSLOG:facility=syslog
      
    • FILE pipes the cluster log output to a regular file on the same machine. The following values can be specified:

      • filename: The name of the log file.

        Prior to MySQL Cluster NDB 7.0.43 and MySQL Cluster NDB 7.1.23, the log file's default name, used if FILE was specified without also setting filename, was logger.log. Beginning with MySQL Cluster NDB 7.0.43 and MySQL Cluster NDB 7.1.23, the default log file name used in such cases is ndb_nodeid_cluster.log.

      • maxsize: The maximum size (in bytes) 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 .N to the file name, where N is the next number not yet used with this name.

      • maxfiles: The maximum number of log files.

      FILE:filename=cluster.log,maxsize=1000000,maxfiles=6
      

      The default value for the FILE parameter is FILE:filename=ndb_node_id_cluster.log,maxsize=1000000,maxfiles=6, where node_id is the ID of the node.

    It is possible to specify multiple log destinations separated by semicolons as shown here:

    CONSOLE;SYSLOG:facility=local0;FILE:filename=/var/log/mgmd
    
  • ArbitrationRank

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    MySQL 5.1.00-210 - 2N

    This parameter is used to define which nodes can act as arbitrators. Only management nodes and SQL nodes can be arbitrators. 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: Indicates a low-priority node which be used as an arbitrator only if a node with a higher priority is not available for that purpose.

    Normally, the management server should be configured as an arbitrator by setting its ArbitrationRank to 1 (the default for management nodes) and those for all SQL nodes to 0 (the default for SQL nodes).

    Beginning with MySQL 5.1.16 and MySQL Cluster NDB 6.1.3, it is possible to disable arbitration completely by setting ArbitrationRank to 0 on all management and SQL nodes. In MySQL Cluster NDB 7.0.7 and later releases, you can also control arbitration by overriding this parameter; to do this, set the Arbitration parameter in the [ndbd default] section of the config.ini global configuration file.

  • ArbitrationDelay

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    MySQL 5.1.0milliseconds00 - 4294967039 (0xFFFFFEFF)N

    An integer value which causes the management server's responses to arbitration requests to be delayed by that number of milliseconds. By default, this value is 0; it is normally not necessary to change it.

  • DataDir

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    MySQL 5.1.0path....N

    This specifies the directory where output files from the management server will be placed. These files include cluster log files, process output files, and the daemon's process ID (PID) file. (For log files, this location can be overridden by setting the FILE parameter for LogDestination as discussed previously in this section.)

    The default value for this parameter is the directory in which ndb_mgmd is located.

  • PortNumberStats

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    MySQL 5.1.0unsigned[none]0 - 64KN

    This parameter specifies the port number used to obtain statistical information from a MySQL Cluster management server. It has no default value.

  • Wan

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    NDB 6.1.1booleanfalsetrue, falseN

    Use WAN TCP setting as default. Introduced in MySQL Cluster NDB 6.1.1.

  • HeartbeatThreadPriority

    Beginning with MySQL Cluster NDB 6.3.32, MySQL Cluster NDB 7.0.13, and MySQL Cluster NDB 7.1.2, it is possible to use this parameter to set the scheduling policy and priority of heartbeat threads for management and API nodes.

    The syntax for setting this parameter is shown here:

    HeartbeatThreadPriority = policy[, priority]
    policy:
      {FIFO | RR}
    

    When setting this parameter, you must specify a policy. This is one of FIFO (first in, first out) or RR (round robin). The policy value is followed optionally by the priority (an integer).

  • ExtraSendBufferMemory

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    NDB 7.0.39bytes00 - 32GN
    NDB 7.1.28bytes00 - 32GN

    This parameter specifies the amount of transporter send buffer memory to allocate in addition to any that has been set using TotalSendBufferMemory, SendBufferMemory, or both.

    This parameter was added in MySQL Cluster NDB 7.0.39 and MySQL Cluster NDB 7.1.28. (Bug #14555359)

  • TotalSendBufferMemory

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    NDB 6.4.0bytes0256K - 4294967039 (0xFFFFFEFF)N

    This parameter is available beginning with MySQL Cluster NDB 6.4.0. It is used to determine the total amount of memory to allocate on this node for shared send buffer memory among all configured transporters.

    If this parameter is set, its minimum permitted value is 256KB; 0 indicates that the parameter has not been set. For more detailed information, see Section 5.3.14, “Configuring MySQL Cluster Send Buffer Parameters”.

  • HeartbeatIntervalMgmdMgmd

    Effective VersionType/UnitsDefaultRange/ValuesRestart Type
    NDB 7.0.40milliseconds1500100 - 4294967039 (0xFFFFFEFF)N
    NDB 7.1.29milliseconds1500100 - 4294967039 (0xFFFFFEFF)N

    Specify the interval between heartbeat messages used to determine whether another management node is on contact with this one. The management node waits after 3 of these intervals to declare the connection dead; thus, the default setting of 1500 milliseconds causes the management node to wait for approximately 1600 ms before timing out.

    This parameter was added in MySQL Cluster NDB 7.0.40 and MySQL Cluster NDB 7.1.29. (Bug #16426805)

Note

After making changes in a management node's configuration, it is necessary to perform a rolling restart of the cluster for the new configuration to take effect.

To add new management servers to a running MySQL Cluster, it is also necessary to perform a rolling restart of all cluster nodes after modifying any existing config.ini files. For more information about issues arising when using multiple management nodes, see Section 3.6.10, “Limitations Relating to Multiple MySQL Cluster Nodes”.