it-swarm.com.de

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 notwendigen Schritte ausgeführt: Dump der Master-DBs, Übertragen des Dumps an den Slave, Löschen der alten DBs, Ausführen des Dumps zum Wiederherstellen der DBs, Ausführen des entsprechenden CHANGE MASTER Befehl und schließlich START SLAVE.

Ich erhalte die Fehlermeldung: 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: enter image description here

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

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 von SHOW SLAVE STATUS\G wie 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:

[email protected] [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
[email protected] [819 18:54:29 /var/lib/mysql]# ls mysql-bin.00029*
mysql-bin.000290  mysql-bin.000291  mysql-bin.000292 #(Yes, it was created)
[email protected] [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
[email protected] [821 18:57:24 /var/lib/mysql]# mysqlbinlog mysql-bin.000289 > /tmp/somefile.txt
[email protected] [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 [email protected]_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
[email protected] [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:

[email protected] [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
10
rinogo

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
6
Andrew

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;
8
Andy Beverley

Die Fehlermeldung ist die Antwort.

Schauen Sie sich die Ausgabe von SHOW BINARY LOGS Abfrage:

+------------------+------------+
| 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.index mit 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;

Probieren Sie es aus !!!

3
RolandoMySQLDBA

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 kritischsten 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 expire_logs_days Abgelaufen (my.cnf, wenn Sie expire_logs_days Festlegen, dass alte Binlogs automatisch ablaufen und entfernt werden; Wenn MySQL eine neue Binlog-Datei öffnet, werden die älteren Binlogs überprüft. und löscht alle, die älter als der Wert von expire_logs_days sind.
  • Jemand hat Binärprotokolle manuell über den Befehl PURGE BINARY LOGS Oder über den Befehl rm -f Vom Master gelöscht
  • Sie haben einige cronjob, die ältere Binärprotokolle archivieren, um Speicherplatz zu beanspruchen

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

Referenz: MySQL-Replikation hat schwerwiegenden Fehler

2
AnouarZ