环境：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
问题描述：
通过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博客 ” ，链接：https://blog.itpub.net/20801486/viewspace-1798122/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
ssh互信配置问题小结
请登录后发表评论
登录
全部评论
