三、190从库延迟问题排查

来自技术开发小组内部wiki
跳转至： 导航、 搜索


190从库复制延迟问题排查

问题说明：
    20170505（周五）04:04 短信预警，189(主)->190(从)复制开始产生延迟，延迟时间一直增长
    
排查思路：
    监控脚本（主从延迟监控：每20s执行一次，异常邮件预警，并附加slave、process、transaction、lock、innodb等状态信息）
    通过邮件中的状态信息slave info项中，可以看到一段时间内exec_master_log_pos卡主不动，一般是由于大事务或DDL操作导致
    解决方法：将大事务拆分多个小事务，或者忽略该事务

一、查看Slave信息
2017-05-05 04:04:21                        #状态时间（间隔20s）
1.The Slave info:
*************************** 1. row ***************************

              Master_Log_File: mysql-bin.002274
          Read_Master_Log_Pos: 10457187                                                    #读取master binog的pos位置
        Relay_Master_Log_File: mysql-bin.002274
          Exec_Master_Log_Pos: 10451292                                                    #slave执行binlog的pos位置；正常情况Read_Master_Log_Pos和Exec_Master_Log_Pos是一致的
        Seconds_Behind_Master: 9                                                                #延迟时间

2017-05-05 04:04:41
1.The Slave info:
*************************** 1. row ***************************
              Master_Log_File: mysql-bin.002274
          Read_Master_Log_Pos: 10462200                                                    #在变化，说明IO_Thread进程没有问题
        Relay_Master_Log_File: mysql-bin.002274
          Exec_Master_Log_Pos: 10451292                                                    #卡主不同，说明SQL_Thread进程在执行一个长时间的事务
        Seconds_Behind_Master: 29                                                                #延迟时间增长

2017-05-05 04:05:01
1.The Slave info:
*************************** 1. row ***************************
              Master_Log_File: mysql-bin.002274
          Read_Master_Log_Pos: 10465803
        Relay_Master_Log_File: mysql-bin.002274
          Exec_Master_Log_Pos: 10451292                                                    #还是不动
        Seconds_Behind_Master: 49                                                                #继续增长


二、查看导致卡主的事务是什么
    使用mysqlbinlog工具，解析binlog日志文件mysql-bin.002274，位置10451292，可以看到
        # at 10451292                    #pos位置
        #170505  4:03:04 server id 1  end_log_pos 10451393      Query   thread_id=2327758723    exec_time=69    error_code=0
        use fmb_new/*!*/;
        analyze table fmb_activity_log                #执行sql语句
    继续查看邮件中其他slave 信息，发现当时的事务都是在执行：analyze table
            ANALYZE TABLE analyzes and stores the key distribution for a table. During the analysis, the table is locked with a read lock for InnoDB and MyISAM.
                该语句 分析和存储一个表的键分布。执行期间，会为MyISAM表加一个读锁
            By default, the server writes ANALYZE TABLE statements to the binary log so that they replicate to replication slaves. To suppress logging, specify the optional NO_WRITE_TO_BINLOG keyword or its alias LOCAL.
                默认情况，服务写ANALYZE语句到binlog以便复制到slave端。如果想忽略记录，制定NO_WRITE_TO_BINLOG或别名LOCAL
    查看系统crontab，找到相应的定时任务
        #每周五，analyze父母帮所有MyISAM表                                 
        03 04 * * 5 /root/script/analyze.sh >> /root/script/analyze.log 2>&

三、解放方案
    在执行任务时，通过修改语句，在master不记录binlog，时该操作不在slave端重放。
        ANALYZE LOCAL TABLE tab_name
    把定时任务复制slave端，目的将该操作分别在主从执行，防止复制导致阻塞其他业务事务。

取自“http://wiki.fumubang.net/index.php?title=三、190从库延迟问题排查&oldid=6223”