web-dev-qa-db-fra.com

Erreur 1236 - "Impossible de trouver le premier nom de fichier journal dans le fichier d'index de journal binaire"

Notre configuration:

  • Maître: MariaDB 10.0.21
  • Esclave: MariaDB 10.0.17

La réplication fonctionnait très bien jusqu'à récemment, moment auquel les bases de données de l'esclave devaient être restaurées à partir d'un vidage. J'ai effectué toutes les étapes nécessaires: vidage des DB du maître, transfert du vidage à l'esclave, suppression des anciens DB, exécution du vidage pour restaurer les DB, exécution du CHANGE MASTER commande, et enfin START SLAVE.

Je reçois l'erreur: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

Le premier fichier journal dont l'esclave a besoin du maître est mysql-bin.000289. Je peux voir que cela est présent sur le maître: enter image description here

Je peux également voir que l'index de journal binaire sur le maître semble avoir une entrée pour ce fichier journal: enter image description here

La réplication ne fonctionne toujours pas - je reçois toujours la même erreur. Je suis à court d'idées - que dois-je vérifier ensuite?


Mise à jour: sortie de SHOW SLAVE STATUS\G comme demandé:

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)

Informations supplémentaires demandées:

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 (extrait):

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

Edit: Postion 342 semble exister:

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
10
rinogo

Vous semblez ne pas vous connecter au maître que vous pensez être. Selon vos journaux binaires sur le maître, vous semblez avoir:

# 160519 3:28:59 id serveur 5

Mais selon SHOW SLAVE STATUS, nous voyons:

         Master_Server_Id: 3

Et de plus, vous semblez vous connecter sur localhost, mais vous avez laissé entendre que votre maître/esclave se trouve sur différents hôtes:

              Master_Host: 127.0.0.1
6
Andrew

Si tout le reste échoue, vous pouvez constater que vous devez réinitialiser l'esclave et redémarrer la réplication. De 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

Le message d'erreur est la réponse.

Regardez la sortie de SHOW BINARY LOGS requete:

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

Il n'y a pas de mysql-bin.000278 sur l'affichage.

À moins que les journaux binaires tournent, le contenu de mysql-bin.index est incorrect.

Veuillez comparer le contenu de mysql-bin.index avec les fichiers binlogs existants et assurez-vous qu'ils correspondent. Vous pouvez résoudre ce problème sur le maître avec

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

puis allez à l'esclave et exécutez

mysql> STOP SLAVE; START SLAVE;

Essayez-le !!!

3
RolandoMySQLDBA

Mise à jour: cette réponse couvre la classification générale des erreurs. Pour une réponse plus spécifique sur la meilleure façon de gérer la requête exacte de l'OP, veuillez consulter les autres réponses à cette question

L'une des erreurs de réplication les plus critiques Erreur fatale obtenue 1236 Elle peut être déclenchée par plusieurs raisons, dont l'une est le titre de cette question.

Erreur fatale 1236 du maître lors de la lecture des données du journal binaire: "Impossible de trouver le premier nom de fichier journal dans le fichier d'index du journal binaire"

Cette erreur se produit lorsque le serveur esclave requis le journal binaire pour la réplication n'existe plus sur le serveur de base de données maître.

De nombreux scénarios peuvent provoquer ceci:

  • Le serveur maître a expiré les journaux binaires via la variable système expire_logs_days (my.cnf si vous définissez expire_logs_days les anciens binlogs expirent automatiquement et sont supprimés; Lorsque MySQL ouvre un nouveau fichier binlog, il vérifie les anciens binlogs et purge ceux qui sont plus anciens que la valeur de expire_logs_days)
  • Quelqu'un a supprimé manuellement les journaux binaires du maître via PURGE BINARY LOGS commande ou via rm -f commande
  • Vous avez un cronjob qui archive les anciens journaux binaires pour réclamer l'espace disque

Afin de résoudre ce problème, la seule solution propre à laquelle je peux penser est de recréer le serveur esclave à partir d'une sauvegarde du serveur maître ou d'un autre esclave dans la topologie de réplication.

Référence: la réplication mysql a une erreur fatale

2
AnouarZ