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

10

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: vider les DB du maître, transférer le vidage vers l'esclave, supprimer les anciens DB, exécuter le vidage pour restaurer les DB, exécuter la CHANGE MASTERcommande appropriée 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: entrez la description de l'image ici

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

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\Gcomme 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
mysql replication mariadb rinogo
la source
Attention également car votre version maître est légèrement plus récente que votre version esclave. Bien que la version esclave puisse être plus élevée (car elle comprendra sans aucun doute toutes les commandes / fonctions / fonctionnalités), si le maître est plus récent, il pourrait invoquer quelque chose dont l'esclave n'a jamais entendu parler. Je soupçonne que cela ne se produirait pas dans une différence de révision aussi mineure, mais ne peut être exclu et serait sans aucun doute Arcane à l'extrême et difficile à trouver. Aussi: la ligne officielle est que le master plus récent n'est pas pris en charge.
TheSatinKnight

Réponses:

6

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 du 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 est sur différents hôtes:

              Master_Host: 127.0.0.1
Andrew
la source
1
Nous utilisons le tunnel SSH (avec autossh ) pour exposer le maître distant localement à 127.0.0.1:3305. J'ai également remarqué le Master_Server_Id, mais je me suis dit que ce n'était qu'un vestige d'il y a longtemps lorsque nous utilisions un autre maître. J'attendais la valeur SHOW SLAVE STATUSde la mise à jour une fois la réplication entièrement rétablie. Quoi qu'il en soit, c'est une suggestion géniale; Je vais vérifier que nous nous connectons bien au bon maître!
rinogo
1
Merci beaucoup de m'avoir pointé dans la bonne direction! Nous étions en effet en train de nous connecter au mauvais maître. Je l'ai confirmé en faisant un telnet 127.0.0.1:3305- je pouvais voir que la version MySQL signalée correspondait à la version de l' ancien maître. Je pense que la racine du problème était probablement due à certaines bizarreries DNS sur notre réseau - il semble que la connexion automatique a été établie par erreur sur domain.com, même si elle a été configurée pour se connecter à db.domain.com. Merci encore une fois.
rinogo
8

Si tout le reste échoue, vous pouvez constater que vous devez réinitialiser l'esclave et redémarrer la réplication. Depuis 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;
Andy Beverley
la source
1
Le PO a indiqué qu'une autre réponse était correcte (et qu'ils se connectaient à la mauvaise instance).
ypercubeᵀᴹ
3
@ yper-trollᵀᴹ - oui, mais la moitié du point de Stackexchange est pour l'archive des questions, qui atterrissent inévitablement en haut de Google recherche d'autres personnes ayant le même problème. J'ai moi-même eu exactement le même problème, et c'était la solution pour moi (surtout que j'ai littéralement passé des heures à essayer de le résoudre, car la plupart des autres pages ne montrent que les mêmes autres réponses). Le fait que l'autre réponse "fausse" ait 2 votes positifs en témoigne.
Andy Beverley
Oui, juste point. Tant que cette (suggestion) est destinée à être utilisée lorsque tout le reste échoue (et clairement marquée comme telle), ça va. C'est pourquoi je n'ai fait que des commentaires et non des votes négatifs.
ypercubeᵀᴹ
1
Cette réponse a fonctionné pour moi quand aucun des autres conseils ne s'appliquait. (Je travaillais sur un binlog existant et actuel, j'avais le maître correctement configuré, etc.) C'est une bonne réponse et franchement le RESET SLAVE; l'option doit être mentionnée plus en évidence ci-dessus.
JD Baldwin
3

Le message d'erreur est la réponse.

Regardez la sortie de la SHOW BINARY LOGSrequête:

+------------------+------------+
| 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.indexavec 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;

Essaie !!!

RolandoMySQLDBA
la source
Salut, Rolando! Merci beaucoup pour votre aide! Malheureusement, je suis toujours confus. Voulez-vous dire mysql-bin.000288au lieu de mysql-bin.000278? Si oui, mysql-bin.000288semble exister. Cela résoudra-t-il toujours le problème?
rinogo
PURGE BINARY LOGS TO 'mysql-bin.000279';m'a donné une erreur (comme on pouvait s'y attendre), car le journal "279" n'existait plus (avait été tourné). PURGE BINARY LOGS TO 'mysql-bin.000288';exécuté avec succès et supprimé tous les journaux binaires jusqu'à "288". Malheureusement, je reçois toujours l'erreur.
rinogo
Merci beaucoup pour vos suggestions détaillées, Rolando! Le problème a fini par être que nous nous connections au mauvais maître ( dba.stackexchange.com/a/140259/55530 ).
rinogo
2

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 traiter la requête exacte de l'OP, veuillez consulter les autres réponses à cette question

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

Obtention de l'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 n'a pas besoin du journal binaire requis pour la réplication 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 les expire_logs_daysanciens 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 une PURGE BINARY LOGScommande ou via une rm -fcommande
  • Vous en avez cronjobqui archivent les anciens journaux binaires pour réclamer de 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 de 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

AnouarZ
la source