MySQL 5.7复制延迟之sync_relay_log

一、描述
MySQL 5.7版本主从复制,批量时候显示延迟上万秒。

二、现象

1、io使用率高
#iostat -dxm 1 1000
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await  svctm  %util
scd0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
vda               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
vdb               0.00    96.00    0.00 2596.00     0.00     8.54     6.74     1.33    0.51   0.37  95.30
vdc               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
vdd               0.00     0.00    0.00   11.00     0.00     0.06    11.64     0.00    0.09   0.09   0.10
vde               0.00     0.00    0.00    7.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
vdf               0.00     0.00    0.00  511.00     0.00     0.00     0.00     0.05    0.09   0.09   4.60
vdg               0.00     0.00    0.00  511.00     0.00     0.00     0.00     0.05    0.09   0.09   4.80
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-2              0.00     0.00    0.00   34.00     0.00     0.23    13.65     0.02    0.59   0.38   1.30
dm-3              0.00     0.00    0.00 2144.00     0.00     8.38     8.00     1.40    0.65   0.45  97.20
dm-4              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-5              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

2、dm3是relay log 和binlog分区
$ ls -l /dev/mapper
total 0
lrwxrwxrwx 1 root root      7 Jul 23 23:20 backup-backup -> ../dm-0
crw-rw---- 1 root root 10, 58 Jul 23 23:20 control
lrwxrwxrwx 1 root root      7 Jul 23 23:20 VG00-lv_root -> ../dm-4
lrwxrwxrwx 1 root root      7 Jul 23 23:20 zxmysql-zxdba -> ../dm-1
lrwxrwxrwx 1 root root      7 Jul 23 23:20 zxmysql-zxlog -> ../dm-3

3、slave状态
mysql> show slave status \G;
*************************** 1. row ***************************
               Slave_IO_State: Queueing master event to the relay log
                略.........................................
                Connect_Retry: 60
              Master_Log_File: mysql-bin.011494
          Read_Master_Log_Pos: 21037034
               Relay_Log_File: relay-log.001904
                Relay_Log_Pos: 3154097
        Relay_Master_Log_File: mysql-bin.011494
             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: 3153884
              Relay_Log_Space: 21037535
              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: 471
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 400011
                  Master_UUID: 0f8507ea-6da1-11e8-8646-005056873c4a
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Reading event from the relay log
           Master_Retry_Count: 86400
                  Master_Bind:
      Last_IO_Error_Timestamp:
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set: 0f8507ea-6da1-11e8-8646-005056873c4a:14137114-19288497
            Executed_Gtid_Set: 0f8507ea-6da1-11e8-8646-005056873c4a:1-19288446
                Auto_Position: 1
         Replicate_Rewrite_DB:
                 Channel_Name:
           Master_TLS_Version:
1 row in set (0.01 sec)

ERROR:
No query specified

三、分析
通过以上现象发现备库io使用率过高,超过90%。io过高的磁盘为日志盘,存放relay log和binlog。io thead一致在写relay log,调用fdatasync写磁盘。这里涉及到一个参数sync_relay_log,默认值为10000,查看当前系统参数值为1.

四、解决方案
优化io thread线程和sql thread线程。sync_relay_log使用默认值,使用mts优化sql thread。

stop slave;
set global slave_parallel_type=logical_clock;
set global slave_parallel_workers=8;
set global sync_master_info=10000;
set global sync_relay_log=10000;
set global sync_relay_log_info=10000;
start slave;

原文地址:https://blog.51cto.com/roidba/2438410

时间: 2024-12-01 19:55:00

MySQL 5.7复制延迟之sync_relay_log的相关文章

实战:mysql 5.6复制延迟监控

#repdelay.sh #!/bin/sh #[email protected] #查看复制延迟具体多少event #set mysql evn MYSQL_USER_MASTER=root MYSQL_PASS_MASTER='password' MYSQL_HOST_MASTER=192.168.2.188 MYSQL_USER_SLAVE=root MYSQL_PASS_SLAVE='password' MYSQL_HOST_SLAVE=192.168.2.14 tmpfile_01="

mysql复制延迟监控脚本

#!/bin/sh #[email protected] #repdelay.sh #查看复制延迟具体多少event #####1.juede the rep slave status export black='\033[0m' export boldblack='\033[1;0m' export red='\033[31m' export boldred='\033[1;31m' export green='\033[32m' export boldgreen='\033[1;32m' e

MySQL 5.7并发复制和mysqldump相互阻塞引起的复制延迟

本来MySQL BINLOG和SHOW PROCESSLIST命令属于八竿子打不着的两个事务,但在最近故障排查中,发现主库和从库已经存在很严重的复制延迟,但从库上显示slave_behind_master值为0,复制SQL线程与备份线程之间相互阻塞,但未报死锁. 在从库上执行SHOW PROCESSLIST发现复制的SQL线程等待锁,而等待SQL的WHERE条件竟然是类似于WHERE C1='ABC' AND C2>'2018-03-01' AND C2<'2018-03-26' 这种个范围查

MySQL主从数据库同步延迟问题解决(转)

最近在做MySQL主从数据库同步测试,发现了一些问题,其中主从同步延迟问题是其中之一,下面内容是从网上找到的一些讲解,记录下来以便自己学习: MySQL的主从同步是一个很成熟的架构,优点为:①在从服务器可以执行查询工作(即我们常说的读功能),降低主服务器压力;②在从主服务器进行备份,避免备份期间影响主服务器服务;③当主服务器出现问题时,可以切换到从服务器. MySQL主从同步故障-Slave_SQL_Running: No http://www.linuxidc.com/Linux/2014-0

seconds_behind_master监控复制延迟的不足及pt-heartbeat改进方法

seconds_behind_master含义及不足 seconds_behind_master的值是通过将salve服务器当前的时间戳与二进制日志中的事件的时间戳相比得到的,所以只有执行事件时才会报告延迟. 1.1  如果备库复制线程没有运行,就会报延迟为null. 1.2  一些错误比如网络不稳定可能导致复制中断或停止复制线程,但是seconds_behind_master将显示为0,而不是显示错误 1.3  即使备库线程正在运行,备库有时候可能无法计算延时,如果发生这种情况,备库会报0或者

Mysql的ab复制

mysql复制在业界里有叫:mysql同步,ab复制等.专业名称就是叫:复制.复制是单向的异步复制,从一个Mysql(Master)复制到另一个Mysql(Slave).实现整个主从复制,需要由Master服务器上的IO进程,和Salve服务器上的Sql进程和IO进程共同完成. 要实现主从复制,首先必须打开Master端的二进制日志(bin-log)功能,因为整个Mysql复制过程实际上就是Slave从Master端获取相应的二进制日志文件,然后在根据相应的Position号在自己Slave端完

MySQL\MariaDB 多线程复制初探

背景: MariaDB 在10.0.0.5就已经支持了并发复制的功能,即从库多线程复制的功能.MySQL最先在5.6.3中支持.目前暂时没有用MySQL5.6的版本,故暂时只对MariaDB进行一些说明,后期会对MySQL进行说明. 对于replication很多同学都已经很熟悉了,这里稍微讲下,在复制过程中有3个线程:Master上的IO线程和Slave上的IO.SQL线程,复制的原理可以自己去google搜.从库一直都是异步复制主库的,通过SHOW SLAVE STATUS 可以查看从库落后

MySQL半同步复制

1.概述 主从复制存在三种类型:异步复制.同步复制以及半同步复制,下面根据手册上解释逐一说明一下. 异步复制: 主库将更新的事件写入binlog,准备好的从库获取这些binlong进行回放.这无法保证所有从库都接到这些事件. ? With asynchronous replication, the master writes events to its binary log and slaves request them when they are ready. There is no guar

Mysql高可用复制原理及主从实例测试解析

一.Mysql复制简介 使用mysql复制功能可以将主数据的数据复制到多台从服务器上.默认情况下,采用异步传输方式,数据复制可以在各种不同的网路环境中进行.主从复制技术在企业生产中得到了广泛应用,它避免了数据库的单点故障,当一台服务器宕机,其他服务器一样可以提供稳定可靠的数据服务. 1 mysql 复制原理 Mysql复制功能是将数据分布在多个系统上,这种机制是通过将Mysql的某一台服务器(master)的数据复制到其它服务器(slaves)上来实现的.复制过程中一个服务器充当主服务器,而一个