First, the principle of MySQL database master-slave replication
MySQL master-slave replication is actually based on binary logs, and the principle can be represented by a diagram:
Divided into four steps:
1. The main library writes all logs generated by DDL and DML into binlog;
2. The main library generates a log dump thread to read binlog for the slave library I/O thread;
3. Request the binlog of the main library from the I/O Thread of the library, and write the obtained binlog log to the relay log file;
4. The SQL Thread of the slave library will read the log in the relay log file and parse it into specific operations, and replay the DDL and DML operation events of the master library.
About DDL and DML
SQL language is divided into four categories: query language DQL, control language DCL, manipulation language DML, definition language DDL.
DQL: can be simply understood as a SELECT statement;
DCL: statements such as GRANT, ROLLBACK and COMMIT;
DML: can be understood as a statement like CREATE;
DDL: INSERT, UPDATE and DELETE statements are all;
Second, the problem of master-slave replication
1. After the main database is down, data may be lost;
2. Master-slave synchronization delay.
Three, MySQL database master-slave synchronization delay causes
Cause Analysis
MySQL's master-slave replication is a single-threaded operation. The master database writes all logs generated by DDL and DML into binlog. Since binlog is written sequentially, it is very efficient. The SQL Thread thread of the slave replays the DDL and DML operation events of the main library in the slave. The IO operations of DML and DDL are random, not sequential, and the cost is much higher. On the other hand, since SQL Thread is also single-threaded, when the concurrency of the main database is high, the amount of DML generated exceeds the speed that the SQL Thread of the slave can handle, or when there is a large query statement in the slave, the delay of lock waiting is generated. is produced.
Common reasons: Master load is too high, Slave load is too high, network delay, machine performance is too low, MySQL configuration is unreasonable.
Fourth, the master-slave delay troubleshooting method
Determine by monitoring the value of the Seconds_Behind_Master parameter output by the show slave status command:
NULL, indicating that either io_thread or sql_thread has failed;
0, the value is zero, indicating that the master-slave replication is good;
A positive value indicates that the master-slave delay has occurred, and the larger the number, the more serious the slave library delay is.
5. Solutions
To solve the problem of data loss:
1. Semi-synchronous replication
Since MySQL 5.5, MySQL has supported semi-synchronous replication. Semi-synchronous replication is between asynchronous replication and synchronous replication. The master library does not return the result to the client immediately after executing the transaction, and needs to wait for at least one slave library to receive it. And write to the relay log before returning the result to the client. Compared with asynchronous replication, semi-synchronous replication improves data security, but it also causes a TCP/IP round-trip time-consuming delay.
2. The main library is configured with sync_binlog=1, innodb_flush_log_at_trx_commit=1
The default value of sync_binlog is 0. MySQL will not synchronize the binlog to the disk. Its value indicates how many binlogs are written to the disk.
innodb_flush_log_at_trx_commit is 1, which means that each transaction commit or instruction outside the transaction needs to flush the log to disk.
Note: When the above two values are set to 1 at the same time, the writing performance will be limited to a certain extent. It is only recommended for scenarios with high data security requirements, such as order payment business involving money, and the system I/O capability. Must be able to support!
To solve the problem of delayed copying from the library:
1. Optimize the network
2. Upgrade Slave hardware configuration
3. Slave adjusts the parameters, closes the binlog, and modifies the innodb_flush_log_at_trx_commit parameter value
4. Upgrade MySQL version to 5.7 and use parallel replication
5. More optimization measures are welcome to add and correct bloggers.....