Solution to the delay problem of MySQL 5.7 master-slave replication

1. The problem is found that
sysbench uses the following configuration to test MYSQL

sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua \
--mysql-host=192.168.1.221 \
--mysql-port=3306 \
--mysql-user=root \
--mysql-password=MySQL5.7 \
--oltp-test-mode=complex \
--oltp-tables-count=10 \
--oltp-table-size=10000 \
--threads=50 \
--time=60 \
--db-driver=mysql \
--report-interval=10 run >sysbench.log

After a period of time, check the status of the slave and find that the delay is serious
mysql> show slave status\G

...
Seconds_Behind_Master: 467
...

2. Reason analysis
A cloud server opens N links for the client to connect, so there will be large concurrent update operations, but there is only one thread that reads the binlog from the cloud server. When a certain SQL is from the cloud The execution time on the server is slightly longer or because a certain SQL needs to lock the table, a large backlog of SQL on the primary cloud server will not be synchronized to the secondary cloud server. This leads to inconsistency between master and slave, that is, master-slave delay.

3. The solution is to enable the new function of MySQL 5.7 to replicate multi-threaded

mysql> show variables like 'slave_parallel%';
+------------------------+----------+
| Variable_name          | Value    |
+------------------------+----------+
| slave_parallel_type    | DATABASE |
| slave_parallel_workers | 0        |
+------------------------+----------+
mysql> set global slave_parallel_type='logical_clock';
mysql> set global slave_parallel_workers=100;   #大小根据需要设置
mysql> start slave;
mysql> show processlist;

4. Check the status after a period of time, and it has returned to normal

mysql> show slave status\G
...
Seconds_Behind_Master: 0
...

Reference:
https://www.yisu.com/zixun/29492.html
https://blog.51cto.com/jim123/1961241