MySQL主从同步延迟

dba@(none) 02:48:05>show slave status\G;
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.15.11
Master_User: dbsync
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.002351
Read_Master_Log_Pos: 276113513
Relay_Log_File: relaylog.007789
Relay_Log_Pos: 178335825
Relay_Master_Log_File: mysql-bin.002339
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 178335662
Relay_Log_Space: 13178574309
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0

 

重启从库，主从同步正常。

 

由于只读从库与主库的同步采用的是单线程同步，而主库的压力是并发多线程写入，这样会导致从库的数据延迟

解决办法：

开启只读从库的并行复制是解决这一问题的根本方法，想彻底解决还得排查业务写入压力是否正常，适当对业务进行优化或者拆分，保证主库的TPS不会导致slave出现延迟。

 

拓展：

在MySQL5.6中，引入了并发复制，这个并发复制是数据库级别的，这意味着一个SQL线程可以处理一个数据库的连续事务，而不用等待其它数据库完成。这个版本的并发复制，可以理解成一个数据库一个SQL线程。其与并发有关的参数如下：

slave_parallel_workers           // worker 线程个数

slave-checkpoint-group           // 隔多少个事务做一次 checkpoint

slave-checkpoint-period          // 隔多长时间做一次 checkpoint

slave-pending-jobs-size-max      // 分发给worker的、处于等待状态的event的大小上限

 

 

 主从延迟的处理思路：
1：从库sql_thread单线程工作

2：长事务（如大的delete/update/alter）会让复制延迟增大

 

MySQL5.6支持库级别的并行复制；

MySQL5.7支持基于事务级的并行复制（group commit）

 

show slave status\G;

在主库执行：mysqlbinlong --base64-output=decode-rows -v --start-position=exec_master_log_pos relay_master_log_file

 基于GTID的主从复制：

主库的UUID值

mysql> select @@server_uuid;
+--------------------------------------+
| @@server_uuid |
+--------------------------------------+
| ffc53fd1-a4f6-11e8-84bb-525400492e59 |
+--------------------------------------+
1 row in set (0.00 sec)

cat /data/mysql_3306/data/auto.cnf
[auto]
server-uuid=ffc53fd1-a4f6-11e8-84bb-525400492e59

主库查询Gtid_Set：

从库查询Gtid_Set：

为什么在从库查询的GTID_SET多出几条？

正常情况下，从库的GTID_SET：UUID是与主库的GTID_SET：UUID值对应，多出的几条是因为该从库做过迁移 ，之前是另一个主库的从库

 做迁移的时候，没有做reset slave all;