Fehler 1236 - "Name der ersten Protokolldatei in binärer Protokollindexdatei konnte nicht gefunden werden"

Unser Setup:

• Meister: MariaDB 10.0.21
• Slave: MariaDB 10.0.17

Die Replikation funktionierte bis vor kurzem einwandfrei. Zu diesem Zeitpunkt mussten die DBs des Slaves aus einem Dump wiederhergestellt werden. Ich habe alle erforderlichen Schritte ausgeführt: Dump der DBs des Masters, Übertragen des Dumps an den Slave, Löschen der alten DBs, Ausführen des Dumps zum Wiederherstellen der DBs, Ausführen des entsprechenden CHANGE MASTERBefehls und schließlich START SLAVE.

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

Die erste Protokolldatei, die der Slave vom Master benötigt, ist mysql-bin.000289. Ich kann sehen, dass dies auf dem Meister vorhanden ist:

Ich kann auch sehen, dass der binäre Protokollindex auf dem Master einen Eintrag für diese Protokolldatei zu haben scheint:

Die Replikation funktioniert immer noch nicht - ich erhalte immer wieder den gleichen Fehler. Ich habe keine Ideen mehr - was soll ich als nächstes überprüfen?

Aktualisiert: Ausgabe SHOW SLAVE STATUS\Gwie gewünscht:

MariaDB [(none)]> SHOW SLAVE STATUS\G
--------------
SHOW SLAVE STATUS
--------------

*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 127.0.0.1
                  Master_User: replication
                  Master_Port: 1234
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000289
          Read_Master_Log_Pos: 342
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 4
        Relay_Master_Log_File: mysql-bin.000289
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
              Replicate_Do_DB: xxx_yyy,xxx_zzz
          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: 342
              Relay_Log_Space: 248
              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: 3
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
                   Using_Gtid: No
                  Gtid_IO_Pos: 
1 row in set (0.00 sec)

Zusätzliche angeforderte Informationen:

root@master [818 18:54:22 /var/lib/mysql]# ls -l /var/lib/mysql/mysql-bin.000289
-rw-rw---- 1 mysql mysql 1074010194 May 19 03:28 /var/lib/mysql/mysql-bin.000289
root@master [819 18:54:29 /var/lib/mysql]# ls mysql-bin.00029*
mysql-bin.000290  mysql-bin.000291  mysql-bin.000292 #(Yes, it was created)
root@master [821 18:56:52 /var/lib/mysql]# mysql -uroot -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 6345382
Server version: 10.0.21-MariaDB-log MariaDB Server

Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> SHOW BINARY LOGS;
+------------------+------------+
| Log_name         | File_size  |
+------------------+------------+
| mysql-bin.000279 | 1074114047 |
| mysql-bin.000280 | 1074004090 |
| mysql-bin.000281 | 1074035416 |
| mysql-bin.000282 | 1073895128 |
| mysql-bin.000283 | 1073742000 |
| mysql-bin.000284 | 1074219591 |
| mysql-bin.000285 | 1074184547 |
| mysql-bin.000286 | 1074217812 |
| mysql-bin.000287 | 1022733058 |
| mysql-bin.000288 |     265069 |
| mysql-bin.000289 | 1074010194 |
| mysql-bin.000290 | 1074200346 |
| mysql-bin.000291 |  617421886 |
| mysql-bin.000292 |     265028 |
+------------------+------------+
14 rows in set (0.00 sec)

MariaDB [(none)]> exit
Bye
root@master [821 18:57:24 /var/lib/mysql]# mysqlbinlog mysql-bin.000289 > /tmp/somefile.txt
root@master [822 18:58:13 /var/lib/mysql]# tail /tmp/somefile.txt 
# at 1074010124
#160519  3:28:59 server id 5  end_log_pos 1074010151    Xid = 417608063
COMMIT/*!*/;
# at 1074010151
#160519  3:28:59 server id 5  end_log_pos 1074010194    Rotate to mysql-bin.000290  pos: 4
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
root@master [823 18:58:31 /var/lib/mysql]# 

/etc/my.cnf.d/server.cnf (Auszug):

# BINARY LOGGING #
log-bin                        = /var/lib/mysql/mysql-bin
expire-logs-days               = 14
sync-binlog                    = 1

Edit: Postion 342 scheint zu existieren:

root@master [826 12:15:33 /var/lib/mysql]# grep "end_log_pos 342 " /tmp/somefile.txt
#160517 14:43:13 server id 5  end_log_pos 342   Binlog checkpoint mysql-bin.000288

Sie scheinen sich nicht mit dem Meister zu verbinden, von dem Sie glauben, dass Sie es sind. Gemäß Ihren Binärprotokollen auf dem Master scheinen Sie:

# 160519 3:28:59 Server-ID 5

Aber gemäß SHOW SLAVE STATUS sehen wir:

         Master_Server_Id: 3

Außerdem scheinen Sie eine Verbindung zu localhost herzustellen, aber Sie haben impliziert, dass sich Ihr Master / Slave auf verschiedenen Hosts befindet:

              Master_Host: 127.0.0.1

Wenn alles andere fehlschlägt, müssen Sie möglicherweise den Slave zurücksetzen und die Replikation neu starten. Von https://www.redips.net/mysql/replication-slave-relay-log-corrupted/ :

# First note current settings
mysql> show slave status\G
# then stop slave
mysql> stop slave;
# make slave forget its replication position in the master's binary log
mysql> reset slave;
# change slave to start reading from stopped position
mysql> change master to master_log_file='mysql-bin.XXX', master_log_pos=XXX;
# start slave
mysql> start slave;

Die Fehlermeldung ist die Antwort.

Schauen Sie sich die Ausgabe der SHOW BINARY LOGSAbfrage an:

+------------------+------------+
| Log_name         | File_size  |
+------------------+------------+
| mysql-bin.000279 | 1074114047 |
| mysql-bin.000280 | 1074004090 |
| mysql-bin.000281 | 1074035416 |
| mysql-bin.000282 | 1073895128 |

Es ist kein mysql-bin.000278 im Display.

Sofern die Binärprotokolle nicht gedreht wurden, ist der Inhalt von mysql-bin.index falsch.

Bitte vergleichen Sie den Inhalt von mysql-bin.indexmit den jetzt vorhandenen Binlogs-Dateien und stellen Sie sicher, dass sie übereinstimmen. Sie können dies auf dem Master mit beheben

mysql> PURGE BINARY LOGS TO 'mysql-bin.000279';

Dann gehe zum Sklaven und renne

mysql> STOP SLAVE; START SLAVE;

Versuche es !!!

Update: Diese Antwort deckt die allgemeine Fehlerklassifizierung ab. Eine genauere Antwort darauf, wie die genaue Abfrage des OP am besten behandelt werden kann, finden Sie in anderen Antworten auf diese Frage

Einer der wichtigsten Replikationsfehler Schwerwiegender Fehler 1236 Er kann aus mehreren Gründen ausgelöst werden. Einer davon ist der Titel dieser Frage.

Beim Lesen von Daten aus dem Binärprotokoll wurde vom Master ein schwerwiegender Fehler 1236 angezeigt: 'Der Name der ersten Protokolldatei in der Indexdatei des Binärprotokolls konnte nicht gefunden werden.'

Dieser Fehler tritt auf, wenn der für die Replikation erforderliche Binärprotokoll des Slave-Servers auf dem Master-Datenbankserver nicht mehr vorhanden ist.

So viele Szenarien können dies verursachen:

• Der Master-Server hat Binärprotokolle über die Systemvariable abgelaufen expire_logs_days(my.cnf, wenn Sie festlegen, dass expire_logs_daysalte Binlogs automatisch ablaufen und entfernt werden; Wenn MySQL eine neue Binlog-Datei öffnet, überprüft es die älteren Binlogs und löscht alle, die älter als der Wert von expire_logs_days sind.)
• Jemand hat Binärprotokolle manuell per PURGE BINARY LOGSBefehl oder rm -fBefehl vom Master gelöscht
• Sie haben einige, cronjobdie ältere Binärprotokolle archivieren, um Speicherplatz zu beanspruchen

Um dieses Problem zu beheben, besteht die einzige saubere Lösung darin, den Slave-Server aus einer Master-Server-Sicherung oder einem anderen Slave in der Replikationstopologie neu zu erstellen.

Referenz: Die MySQL-Replikation hat einen schwerwiegenden Fehler erhalten