MySQL master-slave replication (1)-basic concepts

MySQL master-slave replication (1)-basic concepts

MySQL master-slave replication allows data from one MySQL database server (master server) to be replicated to one or more MySQL database servers (slave servers).

1. The basic principle of master-slave replication

The basis of data replication between MySQL is the binary log. Once the binary log is enabled for a MySQL database, as the master, all operations in its database will be recorded in the binary log in the form of [events]. Other databases act as slaves to communicate with the master server through an I/O thread, and Monitor the changes of the master's binary log file. If it finds that the master's binary log file has changed, it will copy the changes to its own relay log, and then a SQL thread of the slave will execute the relevant [event] to In its own database, to achieve consistency between the slave database and the master database, master-slave replication is also realized. The working principle and working process of

master-slave replication are shown in the following figure: The working process of master-slave replication:

step1. Any modification to the master server will be saved in the Binary log through its own I/O thread;

step2. The I/O thread on the slave server connects to the master server to request to read the binary log through the configured user name and password, and then writes the read binary log to the local relay log (Realy log). At the same time, write the binlog file name (master_log_file) and the latest position (master_log_pos) information returned by the master into the master.info file;

Step3. The SQL thread of the slave server will periodically check the Realy log (relay log and binary log format are exactly the same, also binary), if there is an update, it will immediately execute the updated content on the database.

The above-mentioned master-slave replication work process can also be represented by the following figure:

Note: In the master-slave replication architecture, all updates must be performed on the master server. Otherwise it will cause data inconsistency.

Second, the advantages of mysql master-slave replication architecture

1. Realize the separation of reading and writing. Apply reading and writing to different databases and servers. One database for writing (master, master), one or more databases for reading (slave, slave), each database is located on a different server, making full use of server performance and database performance.

2. Improve the reliability of the system. When the master database fails, the slave database can replace the master database to continue working without affecting the business.

3. Realize load balancing. When the concurrency of the system is large, the number of slave libraries can be expanded and load balancing can be achieved.

Three, the type of replication supported by MySQL

The type of MySQL master-slave replication depends on the binlog log mode of the master database:

1. Statement-based replication. The SQL statement executed on the master server will execute the same statement on the slave server. Configuration: binlog_format ='STATEMENT'.

2. Line-based replication. Copy the changed content instead of executing the command on the slave server. Configuration: binlog_format ='ROW'.

3. Mixed types of replication. By default, statement-based replication is used. Once a statement-based replication is found to be inaccurate, row-based replication will be used. Configuration: binlog_format ='MIXED'.

Four, MySQL master-slave replication architecture

1. The basic principles of building master-slave replication

(1) Each Slave can only have one Master;

(2) Each master and slave must develop a unique server ID (server-id);

(3) Each Master can have many Slaves;

(4) By setting the log_slave_updates parameter, one Slave can become the Master of other Slaves (multi-level replication architecture).

2. One-master multiple-slave replication architecture

Usage scenario: In the scenario where the read request pressure of the main library is very high, you can configure a one-master multi-slave replication architecture to achieve read-write separation, and load a large number of read requests that are not particularly demanding in real-time to multiple slave libraries. , Reduce the reading pressure of the main library. In the case of abnormal downtime of the main library, a slave library can be switched to the main library to continue providing services.

Note:
(1) When the number of slaves is increased to a certain number, the load of the slave to the master and the network bandwidth will become a bottleneck;
(2) different slaves play different roles;
(3) use one slave as the backup master, and only copy ;
(4) Use a remote Slave for disaster recovery.

3. Multi-level replication architecture

Usage scenario: The one-master, multiple-slave architecture can solve most scenarios where the read request pressure is particularly high, but the I/O pressure and network pressure of the main library will increase with the increase of the slave library, and the use of multi-level replication architecture It can solve the additional I/O and network pressure of the main library in the one-master multiple-slave scenario. However, in the multi-level replication scenario, the data in the master library arrives at the slave library for reading after two times, and the delay during this period is greater than that in the one-master, multiple-slave replication scenario and only undergoes one replication.

Note: There may be a risk of longer delay.

4. Dual master replication architecture

Usage scenario: The dual-master architecture is suitable for scenarios where the writing pressure is relatively high, or the scenario where the DBA does maintenance requires a master-slave switch.

Note: The biggest problem is update conflicts.

Five, configure master-slave synchronization

The process of configuring master-slave synchronization can be summarized as the following steps:

step1, the main server: (1) turn on the binary log; (2) configure the server-id; (3) create a user for replication.

step2. On each slave server: (1) Enable relay log; (2) Configure server-id.

step3. Before starting the replication process, record the location information of the binary file on the master server (show master status).

step4. If there is already data in the database before starting to copy, you must first import the data from the master server to the slave server (you can use mysqldump to export the database, or copy the data file directly).

step5. Use the change master command to configure the master-slave replication information.

Step6. From the replication, start the master-slave replication (start slave) and check whether the master-slave replication is successfully configured (show slave status).