MySQL cluster is a high-utility, high-redundancy version of MySQL suitable for distributed computing environments. It employs the NDB cluster storage engine, allowing multiple MySQL servers to run in 1 cluster.
MySQL Cluster is a technology that allows the cluster of an "in-memory" database to be deployed in a system that is not shared. With no shared architecture, the system can use inexpensive hardware and has no special requirements for hardware and software. In addition, because each component has its own memory and disk, there is no single point of failure.
Summarizes some common issues to be aware of when porting to MySQL cluster.
About Connection
MySQL clusters are suitable for use in high-speed bandwidth environments and are connected by TCP/IP. Its performance is directly related to the connection rate between hosts. The minimum rate requirement in a cluster is a conventional 100MB Ethernet or equivalent network. We recommend using a G-class network if possible.
About memory
The MySQL cluster can be run on any NDB enabled platform. Obviously, the faster the CPU, the larger the memory, the more obvious the performance increase for the cluster, the 64-bit CPU may be faster than the 32-bit processor. Each machine that is a data node must have enough memory to hold the shared database.
In MySQL 5.0, the cluster can only be memory-based. This means that all table data, including indexes, are stored in memory. If your data is 1GB large and you want to replicate it to a cluster, then you have to have 2GB of memory (each copy consumes 1GB), which is the additional memory required on the computer running the cluster relative to other operating systems.
If memory usage on a data node exceeds the available range, the operating system uses swap memory to reach the upper value of datamemory. However, this can cause severe performance degradation and may cause the corresponding time to become slower. It is for this reason that we do not recommend the use of disk swap space in a production environment. In any case, all operation requests (such as insertions) will fail as long as the datamemory limit is reached.
A disk-based storage cluster was implemented in MySQL 5.1, but not in 5.0. Indexed fields that contain a primary key hash index must still be saved in RAM, but all other fields can be saved on disk.
It is important to note that each MySQL cluster table requires a primary key. If you do not define a primary key, the NDB storage engine automatically creates an all data node with the same amount of memory, because no data node in the cluster can use more memory than the other data node's minimum memory. In other words, if there are 4 computers in the cluster, if the memory of 3 computers is 3GB and the other one is only 1GB, then each data node can only take out 1GB memory for the cluster.
About security
Communication between the 2 nodes of the MySQL cluster is unsafe; they are not encrypted or protected by any protection mechanism. A secure cluster is a private network that is placed inside a firewall, where data and management nodes cannot be accessed directly from the outside world (SQL nodes are also as secure as other MySQL servers).
About the storage engine
The MySQL cluster only supports the NDB storage engine. That is, if you want a table to be shared among the cluster nodes, you must specify ENGINE=NDB (or Engine=ndbcluster as well).
The MySQL cluster can also use the MyISAM or InnoDB storage engine to create data tables, but those non-NDB tables are not stored among cluster nodes, and they are independent of the MySQL server or instance that was created.
About importing
You can import various versions of MySQL data into the cluster. The only requirement is that the table to be imported must be a NDB storage engine, which is a table created in ENGINE=NDB or Engine=ndbcluster mode.
About data types
The MySQL cluster supports all common data types, except for the type of space extension associated with MySQL (see Chapter, Spatial Extensions for details). In addition, the index of the NDB table is somewhat different.
Note: The MySQL cluster table (that is, the NDB or ndbcluster type table) supports only fixed-length records. This also means (for example) that if a record contains a VARCHAR (255) field, it will require a 255-character space (as large as the character set used by the data table and the space required by the checksum), regardless of the actual number of characters stored. In MySQL 5.1, however, only the portion of the field that is actually occupied by the record is saved.
In the NDB table, the database name, table name, and property name cannot be as long as in other table handlers. The attribute name will be truncated to 31 characters, and if it is not unique after truncation, it will result in an error. The total maximum length of the database name and table name is 122 characters (that is, the maximum length of the NDB cluster table name is 122 characters minus the number of characters in the name of the database to which the table belongs).
About transactions
The tables for the NDB storage engine support transactions. In MySQL 5.0,Cluster only supports Read Committed isolation level。
About foreign keys
The NDB storage engine does not support foreign keys. Like MyISAM, they are not supported.
About Fulltext Index
In MySQL 5.0,NDB Storage Engine does not support fulltext indexes, other than the MyISAM storage engine is not supported.
NDB and InnoDB set checkpoints, regularly write data to disk, and NDB load data into memory when it starts (the disk table loads only the primary key and indexed columns, as mentioned later).
The biggest difference between memory and disk tables is that disk tables only load primary and index columns and indexes into memory, and other columns that are not indexed are saved to disk and stored in a data file in the tablespace. While the memory table is all the columns are load into memory
The memory table reads directly from memory, fast. Disk table if you can use the overwrite index is also very fast, if it is not necessary to navigate through the in-memory primary key index to the disk, reading from the disk will be slower. As for how the NDB starts to load you can take a look at the official documentation and see the detailed start-up process for NDB.
FAQ for MySQL cluster
