MySQL cluster (1)

I have also heard of Renren's solution to replace the normal Mc cache. Then I read the relevant documents and record them here.

 

Mysqlcluster consists of three core components: Cluster Manager, SQL node, and NDB node.

Cluster Manager: similar to a management node, it is responsible for managing SQL nodes and NDB nodes, and also stores metadata information. This requirement for high availability is not high and does not affect services.

SQL node: it is actually a MySQL server with NDB engine installed. It is responsible for providing services but does not store data.

NDB node: Mainly used for data storage. By default, it has full memory and can also be specified as a disk file, also known as data node.

Security Configuration is not mentioned. There are a lot of documents on the Internet.

 

Ha, high availability:

NDB node has the concept of group. For example, there are two NDB nodes: node1 and node2. If the two are a group, the group will store two copies of data, which breaks down and ensures data integrity. If there are four nodes, you can create two groups, data sharding is performed between groups, and data redundancy is performed within a group. Currently, only one NDB node can be started on one machine. A node between a group also has the concept of master and slave. Only one master is allowed. If the master fails, the master is selected from the node.

The official High Availability of SQL node is to start Multiple SQL nodes, but I think this is useless becauseProgramOnly one SQL node can be connected. The front end can be LVS or keepalive to make high availability for multiple sqlnodes.

The biggest advantage of MySQL cluster is that it can dynamically add nodes. Because data is stored in memory, adding nodes is similar to resizing, adding a node requires a restart of NDB manager, SQL node, and NDB node. Because there are multiple data copies, online changes can be made. When a node joins a cluster, data needs to be distributed again, this is also online.

MySQL cluster can also be used for backup and recovery. Similar to creating a snapshot on each data node, a backup file is stored in the directory of each data node, and recovery depends on this.

MySQL Cluster also supports transactions and has its own redo and undo. Redo has a uniform disk, while undo depends on the situation. The memory table is in the memory, and the disk table is in the disk.

MySQL clusters can also be copied between clusters, that is, the two clusters can also be copied. There is a premise that the BINLOG format must be row based and that there is an injector thread to write the BINLOG, why does mysqlserver write BINLOG? Because if mysqlserver writes BINLOG, if the program directly uses ndb api to operate data BINLOG will be much less, so a new thread is started.

MySQL cluster data splitting. The default MySQL cluster sharding method is hash based on the primary key. If there is no primary key, it is created with a unique one. If there is no unique one, it uses the rowid of InnoDB.

 

The performance is not tested, and the full data memory should not be bad. MySQL cluster is currently one of the main products of MySQL, but it seems that everyone is not too familiar with this full-memory solution. More attempts and tests are required to apply it to the production environment.