Dans les architectures à haute disponibilité MySQL, la réplication primaire de la base de données est un type très courant.
Lorsque la base de données principale tombe en panne, vous pouvez mettre à jour une base de données esclave en une nouvelle base de données primaire pour garantir la disponibilité des services. En même temps, le QPS de l’ensemble du cluster peut être amélioré en étendant la bibliothèque d’esclaves.
Dans l’architecture de réplication maître-esclave, MySQL utilise binlog pour obtenir la cohérence des données maître-esclave.
Comme montré dans la figure ci-dessus, la réplication maître-esclave MySQL comprend principalement les étapes suivantes
1. Le maître enregistre les modifications apportées au journal binaire
2. L’esclave io_thread demander le binlog de la bibliothèque principale et écrire le binlog résultant dans le log relais
3. Événements de relecture sql_thread esclave dans le journal de relais
En plus d’être un lien pour la réplication maître-esclave MySQL, binlog remplit également d’autres fonctions. Comme quoi:
1. Utiliser l’outil mysqlbinlog pour analyser le fichier binlog afin d’effectuer une récupération de base de données en temps donné.
2. Flashback de la base de données basé sur des événements binlog (MariaDB peut utiliser directement mysqlbinlog pour le flashback)
3. L’outil open source de modification de tables en ligne gh-ost de Github est également implémenté via binlog
4. Vous pouvez aussi vous abonner et consommer progressivement en analysant les binlogs
Binlog est très utile, mais il est inévitable que vous rencontriez des problèmes dans le processus quotidien d’exploitation et de maintenance. Voici quelques erreurs liées aux binlogs.
L’une des questions fréquemment posées
Phénomène
mysqlbinlog5.5 analyse le fichier binlog mysql5.7 apparaît
ERROR: Error in Log_event::read_log_event(): 'Sanity check failed', data_len: 31, event_type: 35ERROR: Could not read entry at offset 123: Error in log format or read error.
Analyse de la cause
MySQL 5.6 et d’autres versions ultérieures des fichiers binlog ont ajouté de nouveaux événements binlog, tels que les événements GTID.
mysqlbinlog dans mysql5.5 ne reconnaît pas de tels événements binlog.
Solution de contournement
Utilisez la version supérieure de mysqlbinlog pour résoudre le binlog généré par la version inférieure de mysql
Deuxième question fréquemment posée
Phénomène
Un serveur mysql sain affiche le statut d’esclave
Last_SQL_Error : Échec de lecture du journal relais : Impossible d’analyser l’entrée de l’événement du journal relais.
Les raisons possibles sont : le journal binaire du maître est corrompu (vous pouvez vérifier cela en lançant 'mysqlbinlog' sur le journal binaire),
Le journal de relais de l’esclave est corrompu (vous pouvez vérifier cela en lançant 'mysqlbinlog' sur le journal de relais),
un problème de réseau, ou un bug dans le code MySQL du maître ou de l’esclave.
Si vous voulez vérifier le journal binaire du maître ou le journal relais de l’esclave,
vous pourrez connaître leurs noms en indiquant « MONTRER LE STATUT D’ESCLAVE » sur cet esclave.
Analyse de la cause
Les entrées du journal relais ne peuvent pas être lues en raison d’erreurs binlog dans la bibliothèque maîtresse, erreurs de journal relais dans la bibliothèque esclave, ou problèmes et bugs réseau. Elle est généralement causée par une défaillance réseau ou une pression excessive sur la bibliothèque esclave, entraînant un format incorrect du journal relais.
Solution de contournement
Après avoir trouvé le moment de synchronisation actuel et réinitialisé la synchronisation maître-esclave, un nouveau journal relais sera généré et la synchronisation maître-esclave sera restaurée.
D’après la sortie « afficher le statut de l’esclave\G », trouvez les informations suivantes :
Relay_Master_Log_File : mysql-bin.002540 // Le binlogExec_Master_Log_Pos du maître lu par la bibliothèque esclave : 950583017 // Le point de position qui a été exécuté sur l’esclave
Arrêtez l’esclave et reconfigurez la synchronisation en partant du fichier binlog que l’esclave a lu et de la position qui a été exécutée.
Relay_Master_Log_File : mysql-bin.002540 // Le binlogExec_Master_Log_Pos du maître lu par la bibliothèque esclave : 950583017 // Le point de position qui a été exécuté sur l’esclave
Troisième question fréquemment posée
Phénomène
Restaurer le statut d’esclave après une erreur d’arrêt :
Last_SQL_Error : Erreur initialisant la position du journal du relais : erreur d’E/S liant l’en-tête depuis le journal binaire
Last_SQL_Error : Erreur initialisant la position du journal relais : Binlog a un mauvais nombre magique ; Ce n’est pas un fichier journal binaire qui peut être utilisé par cette version de MySQL
Analyse de la cause
Des interruptions, telles que des pannes de courant, des brûlures de la carte mère, etc., ou des arrêts illégaux, entraînant la corruption du fichier de relais
Solution de contournement
Même question deux.
relay_log_recovery = 1 peut également être défini.
Lorsque l’esclave tombe de la bibliothèque, si le journal relais est corrompu et qu’une partie du journal relais n’est pas traitée, le journal relais est automatiquement abandonné et le journal est récupéré depuis le maître, complétant ainsi la récupération du journal relais.
Question foire aux quatre
Phénomène
Apparaît lorsque le master change après un redémarrage depuis la machine de la bibliothèque
Erreur (Code 1201) : Impossible d’initialiser la structure d’information maîtresse ; d’autres messages d’erreur peuvent être trouvés dans le journal d’erreur MySQL
ou
ERREUR 1872 (HY000) : Slave n’a pas réussi à initialiser la structure d’information du journal relais depuis le dépôt
Analyse de la cause
Des interruptions, comme une coupure de courant, des brûlures de la carte mère, etc., ou des arrêts illégaux, endommageant master.info ou realy-log.info fichiers
Solution de contournement
esclave> réinitialiser esclave tout, changer maître en
Mesures préventives
Paramètres du profil
relay_log_info_repository=tableau
master_info_repository=table
Le moteur de stockage de MySQL 5.6.5 mysql.slave_master_info et mysql.slave_relay_log_info est défini sur MyISAM par défaut, et vous devez le changer vers le moteur de stockage d’InnoDB
ALTER TABLE mysql.slave_master_info ENGINE=InnoDB ;
ALTER TABLE mysql.slave_relay_log_info ENGINE=InnoDB ;
mysql.slave_master_info tableau sera mis à jour après sync_master_info événements.
mysql.slave_relay_log_info tableau sera mis à jour à chaque commit de transaction.
Question fréquemment posée 5
Phénomène
L’esclave maître binlog_format à l’origine une affirmation, après avoir changé la base de données principale binlog_format en ligne, afficher le statut de l’esclave apparaît depuis la bibliothèque :
Last_Error : Erreur lors de l’exécution de l’événement de ligne : « Impossible d’exécuter l’instruction : impossible d’écrire dans le journal binaire puisque l’instruction est au format ligne et BINLOG_FORMAT = STATEMENT. »
Analyse de la cause
Lorsque la base principale binlog_format est la ligne, et que la bibliothèque esclave binlog_format est une instruction, l’erreur ci-dessus apparaît.
Mais la bibliothèque principale binlog_format est l’énoncé, et la bibliothèque d’esclaves binlog_format rangée ;
Ou si le binlog_format principal de la base de données est en ligne, l’erreur ne sera pas signalée si le binlog_format de la base de données est mélangé.
Si votre thread SQL est effectivement configuré avec
binlog_format=STATEMENT : dès qu’il reçoit un événement ROW, il s’arrête. Le
la raison est qu’il ne serait pas possible d’enregistrer cet événement ROW en STATEMENTformat (parfois on appelle cela injection ROW, qui est soit un
BINLOG ou un événement ROW exécuté par le thread SQL de l’esclave)
Référence détaillée de la raison :https://bugs.mysql.com/bug.php?id=69095
Solution de contournement
ESCLAVE > ESCLAVE DE BUTÉE ;
ESCLAVENT > DÉFINI GLOBAL binlog_format=MIXTE ;
ESCLAVE > ESCLAVE DE DÉPART ;
Question fréquemment posée numéro 6
Phénomène
Erreur lors de la synchronisation de mysql5.6 avec mysql5.5
Last_IO_Error : Erreur fatale 1236 du maître lors de la lecture des données du journal binaire : « L’esclave ne peut pas gérer les événements de réplication avec la somme de contrôle que le maître est configuré pour enregistrer ; Le premier événement 'mysql-bin.000001' à 4, le dernier événement lu à partir de 'mysql-bin.000001' à 120, le dernier octet lit à partir de 'mysql-bin.000001' à 120.'
Analyse de la cause
Afin de résoudre le problème selon lequel les instructions SQL fonctionnant sur le serveur principal sont incohérentes avec celles qui s’exécutent sur le serveur (appelé « corrompu événement ») en raison d’erreurs logicielles, matérielles ou de transmission réseau, MySQL 5.6 ajoute la fonction de somme de contrôle des événements de réplication. Lorsqu’un événement est écrit dans le journal binaire, la somme de contrôle est également écrite dans le journal binaire, puis, après que l’événement a été transmis à l’esclave via le réseau, il est vérifié sur l’esclave et écrit dans le journal de relais de l’esclave. Puisque les événements et les sommes de contrôle sont enregistrés à chaque étape, nous pouvons rapidement déterminer quel est le problème.
Dans mysql5.6.5 et versions ultérieures binlog_checksum la valeur par défaut est crc32,
La valeur par défaut binlog_checksum version précédente était nulle
solution
Slave> défini global binlog_checksum=aucun
Question fréquemment posée 7
Phénomène
Une fois le disque plein, nettoyez manuellement le fichier binlog et le fichier mysql-bin.index
Les journaux binaires d’affichage sont vides, mais l’état du maître d’affichage est normal.
mysql> afficher les journaux binaires ; Jeu vide (0,00 sec)mysql> afficher l’état du maître ;
+------------------+-----------+--------------+------------------+
| Fichier | Poste | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+-----------+--------------+------------------+
| mysql-bin.001385 | 987114584 | | |
+------------------+-----------+--------------+------------------+
Analyse de la cause
Après avoir vérifié le fichier mysql-bin.index, j’ai trouvé la première ligne blanche.
Dans le code source mysql rpl_master.cc :show_binlogs(), vous trouverez le code suivant :
/* The file ends with EOF or empty line */
tandis que ((longueur=my_b_gets(index_file, fname, sizeof(fname))) > 1)
Les lignes blanches sont considérées comme la fin du document
(Référence.)https://yq.aliyun.com/articles/213657Article)
Mesures préventives
Ne supprimez pas manuellement binlog, ne modifiez pas manuellement le fichier mysql-bin.index, sauf si vous savez ce que vous faites, sinon vous risquez de poser des mines vous-même !
résumé
Les DBA doivent prêter attention aux améliorations du binlog dans chaque nouvelle version de MySQL (comme la fonctionnalité gtid ajoutée dans la version 5.6, les Esclaves Multi-threads améliorés dans la version 5.7), et comprendre en détail la signification de chaque paramètre afin de comprendre ce qu’ils signifient lorsqu’ils rencontrent des erreurs et résoudre facilement des problèmes.
|
Publié sur 25/09/2018 10:31:40
|
|
|
|
