Skip to content

RonDB configuration files#

There is only one configuration file that is absolutely needed for RonDB. This is the cluster configuration file that specifies the nodes that are part of the cluster and a number of configuration parameters for those nodes.

In MySQL it is normal to also use a special configuration file, my.cnf instead of using startup parameters. This file isn't absolutely necessary. Personally I tend to avoid using this since I often get problems in that the MySQL Server finds configuration files that I didn't know about and that causes the setup to be different than I intended. Therefore in the benchmark scripts that I will present later in this book I avoid using the MySQL configuration file.

The configuration file handling for MySQL servers also presents an issue when starting up several MySQL servers on the same machine.

Using the MySQL configuration files makes the starting of the MySQL Server, RonDB management server, RonDB data nodes and RonDB management client easier since most of the parameters can be specified in this file. So for most users this is still the preferred method of providing startup parameters to the MySQL server.

We will start by shortly describing the format of the files and after that describing each file in more detail. The actual configuration parameters will be covered in later chapters since there is a lot of them and some of them requires a fair bit of explanation of how they work and why they exist.

General rules for MySQL configuration files#

A configuration file consists of a number of sections. A section starts like this:

[ndbd]

The cluster configuration file have the following sections that can be used.

[ndbd] or [db] [api] or [mysqld] [ndb_mgmd] or [mgm] [tcp]

api and mysqld are synonyms as are ndb_mgmd and mgm and [ndbd] and [db].

The ndbd, ndb_mgmd, mysqld sections each represent nodes in the cluster, one section per node. One can specify default sections like this:

[ndbd default]

The default sections are normally at the beginning of the file to avoid having to write every changed parameter for each node.

The tcp section represents the communication between two nodes. There is no need to use the [tcp] sections other when communication between two nodes use different configuration than other communication.

Currently only TCP/IP communication and shared memory communication between nodes is possible. Historically there has been a [sci] communication variant. This is no longer used.

Section names and configuration parameters are case insensitive in the cluster configuration file.

After #, the text following this on the rest of the line is treated as a comment.

The my.cnf file uses the same parsing rules for the configuration, also here there are sections provided in the same fashion and comments can be provided. One major difference is that section names and configuration parameters are case sensitive in the my.cnf file.

Cluster configuration file#

Here is a simple example of a cluster configuration file.

The reasoning behind this minimal configuration file is the following.

The RonDB management server must be possible to find for all other nodes. This node must have a static IP address attached to it. The same goes for all other RonDB management servers if there is more than one defined in the cluster. This IP address is specified in the Hostname configuration parameter.

The RonDB data nodes must have a static IP addresses to ensure that they can be found by other data nodes and the RonDB management servers and all the other API nodes. It is required to assign a Hostname to all data nodes in the configuration file.

It isn't strictly required to set a Hostname on the RonDB management server but it is strongly recommended.

It is recommended to use IP addresses in the configuration. This avoids any availability issues with DNS servers while running RonDB.

The MySQL Servers and API nodes can connect from anywhere. The main reason to set Hostname parameter here is to limit the accessibility from any other computer.

Given that MySQL Servers have predefined places and need to have a static IP address for MySQL clients to find them, it makes sense to define Hostname for MySQL Servers as well.

For API nodes that are used to run various RonDB tools it is only necessary to set the Hostname if you want to limit cluster access for security reasons.

It is strongly recommended to set DataDir for both data nodes and management servers although it isn't strictly required.

Similarly it is strongly recommended to set NodeId for both data nodes and management servers since otherwise it will be very hard to manage the cluster. The same applies to MySQL Servers. There is no specific need to set NodeId on API nodes other than to control the number space used by NodeIds.

# Data node defaults
[ndbd default]
DataDir=/path/to/datanode/dir
ServerPort=11860

#NDB management server defaults
[ndb_mgmd default]
DataDir=/path/to/mgm/dir

#The management server node
[ndb_mgmd]
NodeId=65
Hostname=192.168.1.100

#The first data node
[ndbd]
NodeId=1
Hostname=192.168.1.101

#The second data node
[ndbd]
NodeId=2
Hostname=192.168.1.102

#The first MySQL Server
[mysqld]
NodeId=67
Hostname=192.168.1.103

#The second MySQL Server
[mysqld]
NodeId=68
Hostname=192.168.1.104

# 3 API nodes for use by NDB tools
[api]
[api]
[api]

The details of what to use in a basic configuration is covered in the next chapter and later there are more advanced descriptions of how to configure RonDB.

MySQL configuration file#

[mysqld]
ndbcluster
ndb-connectstring=192.168.1.100

[ndbd]
connect-string=192.168.1.100
nodeid=1

[ndb_mgmd]
connect-string=192.168.1.100
config-file=/path/to/config/file
nodeid=65

[ndb_mgm]
connect-string=192.168.100

The MySQL configuration file (my.cnf) contains parameters to the various programs executed in RonDB. The [mysqld] section contains parameters to be used by mysqld when starting. The ndbcluster and ndb-connectstring are mandatory here so they are good candidates to place into my.cnf.

The [ndbd] is used by ndbmtd. The connect-string parameter is good to place here. If only one data node is used per host it makes sense to place the data node id here as well.

The same reasoning applies to the [ndb_mgmd] section, here the placement of the configuration files config-file seems like a useful parameter to place in my.cnf.

There is a section for the ndb_mgm program and here it makes sense to specify the connect-string.

One of the complexities of the my.cnf is that it can execute several my.cnf files before using the command run-time parameters.

This is the order that the search for my.cnf is done.

  1. /etc/my.cnf

  2. /etc/mysql/my.cnf

  3. $MYSQL_HOME/my.cnf

  4. defaults-extra-file

  5. ./my.cnf

  6. ./mylogin.cnf (only MySQL clients)

The defaults-extra-file is specified as a command parameter. This means that potentially up to 6 different configurations files are processed and only after that the run-time parameters are processed. As is clear it is easy to forget about one of those instances of the MySQL configuration file. The complexity here comes from that a distribution might have preinstalled some of those configuration files with values that you don't want to have there.

As long as you are careful about how to handle those configuration files they can be of great help. Personally I have often felt it easier to only use command parameters since all the starting and stopping of programs is executed by scripts anyways. This means that your environment have to use its own configuration file.

The defaults-file command option can be used to specify the one and only my.cnf file to read. To start without any configuration file at all one uses the option --no-defaults-file.