A brief introduction to MySQL master-slave and cluster mode

Table of contents

3. Precautions for master-slave mode deployment

Master-slave mode and cluster mode all use multiple mysql nodes to store and read data in one project.

When the stand-alone mode deployment does not meet the requirements of security, high availability, high concurrency, etc., it is necessary to consider the master-slave mode or cluster mode deployment.

1. Master-slave mode Replication

Master-slave mode, or master-slave architecture, master-slave replication, has the following common schemes: one master and one slave, one master and multiple slaves, multiple masters and one slave, mutual master and backup, cascading replication, etc.
The master database must enable the binary log (binary) function, because all operations of master-slave synchronization are completed based on binary files.
The data synchronization modes are:
- Asynchronous mode : the main library writes the transaction binlog events into the binlog file. At this time, the main library will only notify the dump thread to send these new binlogs, and then the main library will continue to process the submission operation, and these binlogs will not be guaranteed at this time Pass to any slave library node.
- Semi-synchronous mode : the main library only needs to wait for at least one slave library node to receive and Flush binlog to the relay-log file, and the main library does not need to wait for all slave libraries to give feedback to the main library. At the same time, this is just a feedback received, not a feedback that has been fully implemented and submitted.
- Full synchronous mode : After the main library commits the transaction, all slave library nodes must receive, APPLY and submit these transactions, and then the main library thread can continue to do subsequent operations.

1. Master-slave replication means that when the update, insert, and delete operations in the master database cause data changes, the changes will be synchronized to one or more slave databases (slave) in real time.

2. By default, asynchronous replication does not need to maintain long connections.

3. Through configuration, you can choose the library and table you want to synchronize.

2. Cluster mode

The biggest advantage of the cluster is real-time data synchronization and high availability. The data of each node is synchronized and consistent. Unlike the master-slave, sometimes data inconsistency occurs. With high availability, any node downtime will not affect the business.

The cluster mode has the following centralized and common deployment methods:

Cluster mode with read-write separation: some nodes in the cluster only perform write operations, and some nodes only perform read operations, and the data of each node is completely consistent.
Fragmentation (sub-database and sub-table) cluster mode: All nodes in the cluster have the same table structure, and the data stored in each node is different. There are two main fragmentation algorithms, one is the range method (1-100 pieces of data are in node A, 101-200 pieces of data are in node B), and the other is the HASH method (each piece of data is assigned to different storage nodes).
Combined application of read-write separation and sharding mode, deploy in sharding mode first, and then deploy in read-write separation mode for each shard.

3. Precautions for master-slave mode deployment

Commonly used commands (stop the service before executing the command, and then start after executing the command):
- View the master node status: show master status\G;
- View slave node status: show slave status\G;
- Stop synchronization: stop slave;
- Start synchronization: start slave;
- 修改Master_Log_File：CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000026', MASTER_LOG_POS=0;
- Modify master node information: CHANGE MASTER TO MASTER_HOST='192.168.203.141', MASTER_PORT=33060, MASTER_USER='root', MASTER_PASSWORD='123456';
- Delete the binlog file of the current node: PURGE BINARY LOGS TO 'binlog.000001';
- Data operation log location: SHOW BINARY LOGS;
- The real specific location of the data: SHOW GLOBAL VARIABLES LIKE "%datadir%";
The two fields of slave_sql_running and Slave_IO_Running of each node are YES, and the cluster status is normal
The master server checks the status of the master node, the displayed File field, and the slave server checks the status of the slave node, and the displayed Master_Log_File field must be consistent.
If slave_sql_running is No, the master-slave database data may not be synchronized, you can synchronize the data.
Data export command (executed on the mysql server, no need to log in to the database):
- mysqldump -u[username] -h[ip] -p[password] -P[port number] --databases database name --tables table name>exported file name.sql
Database import command ( you need to specify the database when importing, and ensure that the specified database exists ):
- mysqldump -u[username] -h[ip] -p[password] -P[port number] <imported filename.sql