Detailed Explanation of Master-Slave Replication of MySQL from Getting Started to Mastering 【Advanced】

0. Preface

MySQL's master-slave replication and read-write separation are basic concepts in the database field and an important technology to ensure high availability and high performance of the system.

1. 主从复制（Master-Slave Replication）It is an important function of MySQL. This technique allows data on one MySQL database server (master server) to be replicated to one or more MySQL database servers (slave servers). The usage scenarios of master-slave replication mainly include read-write separation, failover, backup, and data analysis. The core principle of master-slave replication is: the master server records its data changes in the binary log (binary log), and the slave server copies these change requests to its own relay log (relay log), and then replays (replay) from the server Following events in the log, the slave's data is consistent with the master's.

2. Read-write separation refers to the separation of data read and data update operations, which are performed on different database servers. This technique is usually used in combination with master-slave replication, where read operations are performed on the slave server and write operations are performed on the master server. The main advantage of read-write separation is that it can significantly improve application performance and scalability, because read operations are usually more frequent than write operations, and distributing the load of read operations to the slave servers can significantly reduce the pressure on the master server.

Implementing MySQL's master-slave replication and read-write separation requires an in-depth understanding of MySQL's architecture and working principles, and many problems may be encountered during the implementation process, such as data consistency issues, delay issues, and fault recovery issues. Therefore, careful consideration and careful implementation are required in actual operation.

1. Introduction to master-slave replication

Master-slave replication is a data backup technology used to replicate data on one MySQL database server to other MySQL servers in real time. Its main function is to perform real-time data backup, and it can perform load balancing on all slave servers.
The process of master-slave replication is roughly as follows: all data changes (such as insert, delete, update, etc.) on the master server will be recorded in binary logs （Binary Log）, which are called binary logs 二进制事件. The slave starts one I/O线程, it connects to 主服务器, reads events from 主服务器on , and writes those events to the slave's . The slave server will also start a SQL thread, which will read the events in the relay log and execute these events to achieve data synchronization with the master server.二进制日志中继日志（Relay Log）

2. Workflow of master-slave replication

1. Data changes on the master server : After data changes are made on the master server, these changes will be recorded in the binary log, and this process is completed by the Binlog thread.

2. From the I/O thread of the server : The I/O thread of the slave server connects to the master server, reads all unsynchronized data from the binary log, and saves the data to its own relay log.

3. From the server's SQL thread : Next, read the relay log from the SQL thread on the server, and replay the SQL statement in it, so as to update the data in the relay log to the database of the slave server.
   

The role of log files in the master-slave replication process （Binary Log）and中继日志（Relay Log）

1. The binary log (Binary Log) is a log file on the master server 记录了所有改变了数据库数据的SQL语句（如INSERT、UPDATE、DELETE等）. Every time a transaction is executed on the primary server, a record is added to the binary log. Binary logs can be used for both master-slave replication and data recovery.

2. The relay log (Relay Log) is a log file on the slave server 其内容来自主服务器的二进制日志。从服务器上的I/O线程负责从主服务器读取二进制日志中的事件，并将这些事件写入到中继日志中. Then, the SQL thread on the slave server is responsible for reading and executing the events in the relay log to achieve data synchronization with the master server.

There are also some other types of logs, such as Error Log, Slow Query Log, etc., which play a relatively small role and importance in master-slave replication.

3. MySQL master-slave replication configuration

1. Configure MySQL on the master server, open the MySQL configuration file my.cnf of the master server (Depending on the system, it may be in /etc/mysql/my.cnf, /etc/my.cnf, or /usr/local/mysql/etc/my.cnf) Add or change the following configuration:

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log

server-id needs to be set to a unique number, and log_bin defines the location of the binary log file.

2. Restart the MySQL service to apply the new configuration,

service mysql restart

3. Create a user for replication on the master server and give it the required permissions:

mysql> CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
mysql> GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

4. Check the status of the master server:

mysql> SHOW MASTER STATUS;

Execute SHOW MASTER STATUS;the command, you can see output similar to the following:

+------------------+----------+--------------+------------------+-------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000001 |      107 |              |                  |                   |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)

Here File(mysql-bin.000001) and Position(107) are important information that needs to be used when setting up the slave server, and these two values ​​need to be recorded.
Write down the values ​​of File and Position, which will be used when configuring the slave server。

5. Next, you also need to configure on the slave server, edit the my.cnf file, add or change the following configuration:

[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log

The server-id here needs to be different from that of the main server。

6. Restart the MySQL service on the slave server.

7. Set up replication on the slave server, use the user created on the master server before, and write down the sum Fileand Positionfill in MASTER_LOG_FILEandMASTER_LOG_POS

mysql> CHANGE MASTER TO MASTER_HOST='master_host_name',
    -> MASTER_USER='repl',
    -> MASTER_PASSWORD='password',
    -> MASTER_LOG_FILE='recorded_log_file_name',
    -> MASTER_LOG_POS=recorded_log_position;

8. Start copying:

mysql> START SLAVE;

Sometimes output if it fails
If the slave is not configured correctly, you may see an error message like this:

ERROR 1201 (HY000): Could not initialize master info structure; more error messages can be found in the MySQL error log

If you want to check the status of the slave server to confirm whether it has been successfully started, you can execute SHOW SLAVE STATUS;the command. This will display various status information from the server.
9. Use the following command to check the status of the slave server to ensure that replication is running properly:

mysql> SHOW SLAVE STATUS\G;

If the configuration is correct and the master-slave replication is running normally, you should see "Slave_IO_Running: Yes" and "Slave_SQL_Running: Yes"。

Example of a successful result:

mysql> SHOW SLAVE STATUS;
+------------------+-------------+-------------+-------------+---------------+------------------+-------------------+-------------------+...
| Slave_IO_State   | Master_Host | Master_User | Master_Port | Connect_Retry | Master_Log_File  | Read_Master_Log_Pos | Relay_Log_File    |...
+------------------+-------------+-------------+-------------+---------------+------------------+-------------------+-------------------+...
| Waiting for master to send event | localhost | root        | 3306          | 60              | mysql-bin.000002  | 323              | mysq...
+------------------+-------------+-------------+-------------+---------------+------------------+-------------------+-------------------+...
1 row in set (0.00 sec)

in the execution result. The IO thread is waiting for the main server to send events. The main server is a MySQL server running locally. The user name to connect to the main server is root and the port is 3306. If the connection fails, it will retry every 60 seconds. The binary log file of the main server The name is mysql-bin.000002, the position read from the master server's binary log file is 323, and the slave server's relay log file name is mysql-relay-bin.000001.

SHOW SLAVE STATUS;The command returns a line consisting of the replication slave status variables

• Slave_IO_State: The current state
  Slave_IO_Statecolumn of the slave IO thread indicates the state of the replication I/O thread. Here are several common states:

1. Connecting to master: Indicates that it is connecting to the master server.
2. Waiting for master to send event: Indicates that the connection has been established and is waiting for the master server to send binary log events.
3. Reading event from the master: Indicates that a binary log event is being read from the master server.
4. Waiting to reconnect after a failed master event read: Indicates that the binary log event of the primary server failed to be read, and the connection is waiting to be retried.
5. Waiting for the slave SQL thread to free enough relay log space: Indicates waiting for the replication SQL thread to release enough relay log space.
6. Queueing master event to the relay log: Indicates that events read from the master are written to the relay log.
7. Waiting for master to send event: Indicates that a new event is waiting.
8. Checking master version: Check the version of the master server.
9. Registering slave on master: Register the slave server on the master server.
10. Requesting binlog dump: Request the primary server to send binary logs.
11. Waiting to reconnect after a failed binlog dump request: Wait for a reconnect after a failed request to the binary log.
12. Finished reading one binlog; switching to next binlog: Finish reading a binary log and switch to the next binary log.

• Master_Host: The hostname or IP of the master server
• Master_User: The username to connect to the master server
• Master_Port: The port of the master server
• Connect_Retry: If the connection fails, the retry interval (seconds)
• Master_Log_File: The binary log file name of the master server
• Read_Master_Log_Pos: The position to read from the master's binary log file
• Relay_Log_File: The relay log file name of the slave server
• Relay_Log_Pos: The position to read from the server's relay log file
• Relay_Master_Log_File: The master server binary log file name in the relay log
• Slave_IO_Running: Whether the IO thread is running
• Slave_SQL_Running: Whether the SQL thread is running
• Replicate_Do_DB: The database to be replicated, if no database is specified, this item is empty
• Replicate_Ignore_DB: The database to ignore, if no database is specified, this item is empty
• Last_Errno: The error number of the last error
• Last_Error: The error message of the last error

4. References

1. 官网 MySQL 8.0 Reference Manual -17 Replication：https://dev.mysql.com/doc/refman/8.0/en/replication.html

2. The "SHOW SLAVE STATUS Syntax" section explains Slave_IO_State in detail: https://dev.mysql.com/doc/refman/8.0/en/show-slave-status.html