【Mysql】Slave_IO_Running: No---Got fatal error 1236 from master

本地MySQL環境，是兩臺MySQL做M-M複製。今天發現錯誤資訊：

mysql 5.5.28-log> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State:
                  Master_Host: 88.88.88.88
                  Master_User: replicate
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: testdbbinlog.000005
          Read_Master_Log_Pos: 98359687
               Relay_Log_File: mysql-relay-bin.000020
                Relay_Log_Pos: 4
        Relay_Master_Log_File: testdbbinlog.000005
             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: 98359687
              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: 1
1 row in set (0.00 sec)

mysql 5.5.28-log>

參考網上文件： http://blog.csdn.net/billfanggs/article/details/8905991

在source那邊，執行：

flush logs;
show master status;        

記下File, Position。             ---記錄一個新的binlog

在target端，執行：

CHANGE MASTER TO MASTER_LOG_FILE='testdbbinlog.000008',MASTER_LOG_POS=107;   ---從新的binlog開始複製，跳過舊的binlog。
slave start;
show slave status \G

一切正常。 但是會有資料丟失，可以檢查後重新搭建從庫






如果使用了GTID新的特新
（原英文地址https://www.percona.com/blog/2013/02/08/how-to-createrestore-a-slave-using-gtid-replication-in-mysql-5-6/）
How to restore a slave in a bad and fast way（快速但不好的方法）

Let’s imagine that our slave has been down for several days and the binary logs from the master have been purged. This is the error we are going to 

And we set it on the slave:

Error! Remember, we get the GTID_EXECUTED from the master and set is as GTID_PURGED on the slave

Error again, GTID_EXECUTED should be empty before changing GTID_PURGED manually but we can’t change it with SET because is a read only variable. The only way to change it is with reset master (yes, on a slave server):

How to restore a slave in a good and slow way（慢但是比較好的方法）

The good way is mysqldump again. We take a dump from the master like we saw before and try to restore it on the slave

Wop! It is important to mention that these kind of error messages can dissapear on the shell buffer because the restore of the dump will continue. Be cautious.

Same problem again so same solution too:

模擬實驗