NDB is an "in-memory" storage engine that features high availability and good data consistency.
The ability to configure the NDB storage engine with multiple failover and load balancing options, but it is easiest to start with a storage engine at the cluster level. The NDB storage engine of the MySQL cluster contains the complete dataset, depending only on other data within the cluster itself.
Below, we describe how to set up a MySQL cluster consisting of a NDB storage engine and some MySQL servers.
Currently, the cluster part of the MySQL cluster can be configured independently of the MySQL server. In a MySQL cluster, each part of a cluster is treated as 1 nodes.
Note: In many cases, the term "node" is used to refer to a computer, but when discussing a MySQL cluster, it represents a process. There can be any number of nodes on a single computer, so we use the term cluster host.
There are three cluster nodes, in the lowest MySQL cluster configuration, at least three nodes, these three types of nodes are:
• Management (MGM) node: the role of such nodes is to manage other nodes within the MySQL cluster, such as providing configuration data, starting and stopping nodes, running backups, and so on. Since such nodes are responsible for managing the configuration of other nodes, you should start these nodes first before starting other nodes. The MGM node was started with the command NDB_MGMD.
• Data nodes: This type of node is used to hold the data of the cluster. The number of data nodes is associated with the number of replicas, which is a multiple of fragments. For example, for two replicas, each copy has two fragments, and then there are 4 data nodes. There is no need to have more than one copy. The data node is started with the command ndbd.
· SQL node: This is the node that is used to access the cluster data. For MySQL clusters, the client node is a traditional MySQL server that uses the NDB cluster storage engine. Typically, the SQL node is started using the command Mysqld–ndbcluster, or Ndbcluster is added to the my.cnf and then started with mysqld.
The cluster configuration includes the configuration of individual nodes in the cluster and the setting up of separate communication links between nodes. For the current design of the MySQL cluster, the intention is that from the processor's capabilities, memory space and bandwidth, the storage nodes are homogeneous, in addition, in order to provide a single configuration point, as a whole, the cluster of all configuration data are located in 1 configuration files.
The Management Server (MGM node) manages the cluster configuration file and the cluster log. Each node in the cluster retrieves the configuration data from the Management Server and requests a way to determine where the Management server resides. When interesting events occur within a data node, the node transmits information about such events to the Management Server, and then writes such information to the cluster log.
In addition, you can have any number of cluster client processes or applications. They fall into two categories:
• Standard MySQL client: for MySQL clusters, they are no different from standard (non-clustered) MySQL. In other words, you can access the MySQL cluster from existing MySQL applications written in PHP, Perl, C, + +, Java, Python, Ruby, and so on.
• Manage clients: This type of client is connected to the Management Server and provides commands for gracefully starting and stopping nodes, starting and stopping message tracking (Debug versions only), displaying node versions and status, starting and stopping backups, and so on.