一次MySQL主从搭建出现“Last_IO_Errno: 1236”错误的处理记录

今天在搭建一个MySQL master-slave集群时，执行了change master命令，然后又 start slave 启动slave服务，结果查看salve状态就出现错误了：

mysql> show slave status\G

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

               Slave_IO_State:

                  Master_Host: 192.168.62.108

                  Master_User: repl

                  Master_Port: 3307

                Connect_Retry: 60

              Master_Log_File: mysql-bin.000544

          Read_Master_Log_Pos: 76175557

               Relay_Log_File: mysql-relay-bin.000001

                Relay_Log_Pos: 4

        Relay_Master_Log_File: mysql-bin.000544

             Slave_IO_Running: No

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

              Relay_Log_Space: 107

              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

Master_SSL_Verify_Server_Cert: No

                Last_IO_Errno: 1236

                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

               Last_SQL_Errno: 0

               Last_SQL_Error:

  Replicate_Ignore_Server_Ids:

             Master_Server_Id: 621083307

1 row in set (0.00 sec)

错误提示的内容，按照字面意思：

最后的IO错误为 1236； 当从binlog 中读取数据时，master返回一个1236的错误——在binlog索引文件中不能找到第一个日志文件。

之前我遇到这个错误，是因为搭建salve库时，使用的备份是master库7天前的备份，binlog设置默认保留天数为7天，过期的binlog日志文件都会被删除了。所以当时找不到最初binlog日志文件，所以提示这个错误。

于是我登录到 mysql master服务器上确认， mysql-bin.000544日志文件就是今天早上的，目前master正在写入的日志是mysql-bin.000550，肯定是存在，按说是可以读到的。

我查看是否还有其他原因，在网上一篇文章中看到，提示这样错误的原因可能是binlog日志文件不存在，或者binlog的名称没有写对，有空格。这个说法提醒了我，我的操作都是有记录的，赶快去确认开始执行的 change master 命令，结果发现是因为 一开始在进行 change master 命令时，binlog文件 的名称多一个空格，造成了binlog文件名称发生了变化，所以就找不到了。

处理方法：重新stop slave, 修改 change master确保binlog日志文件名称没有空格是正确的, 然后start slave 后状态正常。

通过这次故障，可以看出DBA在进行日常操作和故障处理时，还是需要更多的耐心和细心，这样才能避免更多的问题，尽快解决已经发生的问题。

************************************************

附：出现问题时查询到的网页内容为

网页地址： http://blog.chinaunix.net/uid-20778583-id-3874530.html

MySQL Slave复制故障3例

1.Sandy飓风导致NYC机房停电，重启后看到的日志如下： 

121101 16:35:25 [ERROR] Slave I/O: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position', Error_code: 1236

121101 16:35:25 [Note] Slave I/O thread exiting, read up to log 'mysql-bin.014497', position 38542146

121101 16:41:36 [Note] Error reading relay log event: slave SQL thread was killed

然后看binlog如下：

# at 38539267

#121101 13:11:04 server id 1  end_log_pos 38539294      Xid = 934362432

COMMIT/*!*/;

DELIMITER ;

# End of log file

ROLLBACK /* added by mysqlbinlog */;

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

master突然当机造成的master的pos要小于slave的错误日志记录的pos，mysql-bin.014497的最后一个位置是: end_log_pos 38539294，但没有被commit，所以上一个是 38539267 那么直接设pos为master的最后有效的位置即可，

change master to master_log_file='mysql-bin.014497',master_log_pos=38539267;

但也有可能情况相反，可能slave丢了部分数据或延迟，此时把pos往前移，反复试验即可。

2. Got fatal error 1236: 'Could not find first log file name in binary log index file' from master when reading data from binary log

logfile有空格，或是master上对应的Log被删了。

3. Show processlist 看到很多sleep,可能是应用代码做完query之后没用close()主动关闭链接。这样会一直到timeout才断掉，但这个timeout太小的话，会导致mysql has gone away 这种错误。