Dieser Fehler 1236 ("Got fatal error 1236 from master when reading data from binary log") bedeutet, dass es eine Inkonsistenz in der Datei "mysql-bin.index" des Slave-Servers gibt.
Dieses Tutorial ist Teil der Tutorial-Reihe "MySQL-Replikation".

Wenn die Replikation Ihres Datenbankservers nicht mehr funktioniert, dann könnte dies der Fehler sein. Sie können diese Fehlermeldung im Status Ihres Slave-Servers sehen.

 

mysql> show slave status \G
*************************** 1. row ***************************
[...]
Slave_IO_State:
Master_Host: 32.XXXX
Master_User: duplizierer
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000603
Read_Master_Log_Pos: 510772
Relay_Log_File: mysql-relay-bin.000017
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 dex file'
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_UUID: d6fb7551-5834-11e7-98d3-00224d7cbe03
Master_Info_File: /var/lib/mysql/master.info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
[...]
1 row in set (0.06 sec)

 

Die Lösung für dieses Problem ist nicht kompliziert. Sie müssen Ihre "master_log_file" neu laden und den Slave zurücksetzen.

 

In Ihrem Master-Server

Zunächst einmal müssen Sie während dieser Konfiguration den Zugriff von außen auf Ihren Datenbankserver unterbinden, um Dateninkonsistenz zu vermeiden.

Überprüfen Sie dann den Status Ihres Master-Servers.

 

mysql> show master status \G
*************************** 1. row ***************************
File: mysql-bin.001202
Position: 1017657
Binlog_Do_DB: 
Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)

Bitte merken Sie sich den Wert von "position" (hier: 1017657) und den Wert von "file" (hier: mysql-bin.001202), die später im Slave-Server verwendet werden.

Erstellen Sie ein Backup (Dump) Ihres MySQL-Datenbankservers:

sudo mysqldump -u root -p --single-transaction --add-drop-database --all-databases > /database_master_dump.sql

Wenn Sie nur eine bestimmte Datenbank replizieren, dann verwenden Sie diesen Befehl:

sudo mysqldump -u root -p --single-transaction --add-drop-database --databases MY-DATABASE > /database_master_dump.sql

 

In Ihrem Slave-Server

1. Melden Sie sich bei Ihrem MySQL-Server an und stoppen Sie Ihren Slave-Server

stop slave;

2. Setzen Sie Ihren Slave-Server zurück

reset slave;

3. Melden Sie sich jetzt von Ihrem MySQL-Server ab und importieren Sie Ihre Datenbanksicherung:

mysql -u root -p < /database_master_dump.sql

4. Melden Sie sich erneut bei Ihrem MySQL-Server an und führen Sie diesen Befehl aus:

mysql> change master to master_log_file='mysql-bin.001202', master_log_pos=1017657;

Sie müssen die Werte eingeben, die im Status des Master-Servers angezeigt wurden.

5. Starten Sie nun Ihren Slave-Server

start slave;

 

Schließlich können Sie jetzt den vollen Zugriff auf Ihren Datenbankserver Ihres Master-Servers erlauben.

 

Sie können den Status Ihres Slave-Servers überprüfen, um festzustellen, ob Sie die Inkonsistenzen behoben haben.

show slave status \G

Wenn Sie mehrere Slave-Server haben, dann wiederholen Sie die Schritte von 1 bis 5 noch einmal.

 

Wie lässt sich dieser Fehler vermeiden?

Inkonsistenz kann in seltenen Fällen auftreten, aber Sie können die Chancen für diese Art von Fehler verringern, indem Sie in Ihrem Slave-Server nur lesenden Zugriff auf Ihre replizierten Datenbanken erlauben.

Mehr über Fehler in MySQL:
https://dev.mysql.com/doc/refman/8.0/en/problems.html