MySQL案例之——生产slave库无法应用日志

环境：percona-server 5.6.21-70.1-log 

问题描述：
    通过show slave status监控到 从库io thread线程能够正常接收binlog,但是 Relay_Log_File和 Relay_Log_Pos这两个指标一直处于停顿状态，从现象上看sql thread一直没有正常应用日志。

诊断过程：
mysql> show processlist;
+----+-------------+-----------------+-----------+---------+--------+----------------------------------+------------------+-----------+---------------+
| Id | User        | Host            | db        | Command | Time   | State                            | Info             | Rows_sent | Rows_examined |
+----+-------------+-----------------+-----------+---------+--------+----------------------------------+------------------+-----------+---------------+
| 26 | system user |                 | NULL      | Connect |    534 | Waiting for master to send event | NULL             |         0 |             0 |
| 27 | system user |                 | NULL      | Connect | 111738 | System lock                      | NULL             |         0 |             0 |
+----+-------------+-----------------+-----------+---------+--------+----------------------------------+------------------+-----------+---------------+
从show processlist信息可以看出sql thread一直在遭遇system lock。

mysql err日志信息：
2015-09-09 17:46:44 23701 [Note] Slave I/O thread: connected to master 'xxxx @yyyyy :zzzzz',replication started in log 'mysql-bin.008454' at position 93488738
2015-09-09 17:48:06 23701 [Warning] Slave SQL: If a crash happens this configuration does not guarantee that the relay log info will be consistent, Error_code: 0
2015-09-09 17:48:06 23701No [te] Slave SQL thread initialized, starting replication in log 'mysql-bin.008454' at position 93488738, relay log './ -relay-bin.000001' position: 4
err日志中的警告信息对复制功能没有任何影响，这条信息主要是因为mysql5.6开始支持slave crash-safe repliaction功能，可以将master.info和relay-log.info的信息
写入到数据库表中。

show slave status\G
.....
               Relay_Log_File:relay-bin.000002
                Relay_Log_Pos: 90773529

.....
通过show slave status确定relay-log hang住的位置。

通过mysqlbinlog分析relay-log hang住的position所在的内容：
mysqlbinlog  --base64-output=decode-rows --start-position=90773529 relay-bin.000002
通过分析日志内容发现hang住的位置正在对一个test.xxx表进行delete操作，该表有300多万行的数据，和开发沟通后发现此为测试表，可以忽略这个事务。


解决方案：
1.首先停止slave
2.设置全局参数sql_slave_skip_counter=N来跳过N个event
3.最后启动slave
关于对sql_slave_skip_count参数的正确理解可以参考下面的链接，写的不错：
http://dinglin.iteye.com/blog/1236330

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/20801486/viewspace-1798122/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/20801486/viewspace-1798122/