mysql slave io_解决 mysql 从库 Slave_IO_Running: No

由于主库的主机192.168.1.1宕机,再次启来后，从库192.168.71.1连接主库发现报错. Slave_IO_Running: No

root@192.168.71.1:~# mysql -uroot -p --socket=/opt/mysql/3399/3399.sock

Enter password:

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 452723

Server version: 5.0.51a-24+lenny2 (Debian)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> show slave status\G;

*************************** 1. row ***************************

Slave_IO_State:

Master_Host: 192.168.1.1

Master_User: repl

Master_Port: 3306

Connect_Retry: 60

Master_Log_File: 99.000302

Read_Master_Log_Pos: 165112917

Relay_Log_File: 3399-relay-bin.000013

Relay_Log_Pos: 165113047

Relay_Master_Log_File: 99.000302

Slave_IO_Running: No

Slave_SQL_Running: Yes

Replicate_Do_DB:

Replicate_Ignore_DB: mysql

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: 165112917

Relay_Log_Space: 165113047

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: NULL

1 row in set (0.00 sec)

查看错误日志

mysql@192.168.71.1:/opt/mysql/3399$ cat 192.168.71.1.err

140115  1:51:01 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)

140115  1:51:01 [ERROR] Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log

140115  1:51:01 [Note] Slave I/O thread exiting, read up to log '99.000302', position 165112917

根据错误位置,查找主库上log ‘99.000302’ 对应的位置 165112917

root@192.168.1.1:mysql.bin# mysqlbinlog 99.000302 > /tmp/test

root@192.168.1.1:mysql# tail -n 10 /tmp/test

#140115  0:50:25 server id 1176  end_log_pos 165111351 Querythread_id=111exec_time=0error_code=0

SET TIMESTAMP=1389718225/*!*/;

INSERT INTO user_info_db_86.region_info_table_56 (userid, region, gameflag) VALUES (563625686, 0, 2) ON DUPLICATE KEY UPDATE gameflag = (gameflag | 2)/*!*/;

# at 165111351

#140115  0:50:25 server id 1176  end_log_pos 165111378 Xid = 17877752

COMMIT/*!*/;

DELIMITER ;

# End of log file

ROLLBACK /* added by mysqlbinlog */;

/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

结果发现主库上位置最后是165111351 比165112917要小. 也就是从库同步找的位置比主库要大，故同步不成功

为什么会这样,这是因为这个在sync_binlog=0的情况，很容易出现。

sync_binlog=0，当事务提交之后，MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘，而让系统自行决定什么时候来做同步，或者cache满了之后才同步到磁盘。

sync_binlog=n，当每进行n次事务提交之后，MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

在MySQL中系统默认的设置是sync_binlog=0，也就是不做任何强制性的磁盘刷新指令，这时候的性能是最好的，但是风险也是最大的。因为一旦系统Crash，在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候，是最安全但是性能损耗最大的设置。因为当设置为1的时候，即使系统Crash，也最多丢失binlog_cache中未完成的一个事务，对实际数据没有任何实质性影响。从以往经验和相关测试来看，对于高并发事务的系统来说，“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。

这里由于mysql是默认配置所以该报错原因是： sync_binlog=0时 ，master binlog文件的flush log buffer(这个buffer是由于binlog文件的os buffer)  到disk是依赖于OS本身的，但Slave IO 线程在读取master dump 线程的位置，一般是直接读取log buffer的,这个位置，可能远远大于binlog文件实际大小。 所以当主机宕机后，binlog buffer未刷盘，当Master主机再次启动后，此时从库的binlog pos 165112917 已经比实际的binlog位置大小165111351 还大了。

解决方法:

直接做change master to到当下一个binlog。

CHANGE MASTER TO

MASTER_HOST='192.168.1.1',

MASTER_USER='repl',

MASTER_PASSWORD='replpass',

MASTER_PORT=3306,

MASTER_LOG_FILE='99.000303',

MASTER_LOG_POS=98;