Introduction aux problèmes de journalisation courants dans MySQL

Cet article vous présente une introduction aux problèmes de journalisation courants dans MySQL. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il vous sera utile.

Il existe deux journaux dans MySQL, à savoir : le journal redo et le journal d'archive (binlog). (Cours recommandés : Tutoriel MySQL)

Parmi eux, binlog peut être utilisé pour les bases de données de secours, ou il peut être enregistré pour restaurer les données historiques de la base de données. Il est implémenté au niveau du serveur et peut être partagé par tous les moteurs. Le journal redo est un journal unique à InnoDB et est utilisé pour prendre en charge les fonctionnalités de sécurité en cas de crash.

Vous devez avoir entendu parler de la validation en deux phases des transactions MySQL, ce qui signifie que lorsque la transaction est soumise, elle est divisée en deux étapes : préparer et valider.

La figure 1 montre le processus d'exécution d'une transaction. Vous pouvez voir dans les trois dernières étapes que la préparation du journal redo est terminée en premier, puis le binlog est écrit et enfin l'étape de validation du journal redo est entrée.

Figure 1 Schéma de soumission en deux étapes

Ici, je veux d'abord vous expliquer un malentendu : cette image n'est-elle pas l'exécution d'une mise à jour déclaration ? Processus ? Comment se fait-il que l'instruction de validation soit appelée ?

Habituellement, la raison pour laquelle vous vous posez cette question est que vous confondez les deux concepts de « commit » :

dans la question La « déclaration de commit » fait référence à la commande utilisée pour valider une transaction dans la syntaxe MySQL. Généralement utilisé conjointement avec start/start transaction.

L'« étape de validation » utilisée dans notre image fait référence à une petite étape dans le processus de soumission de la transaction et constitue également la dernière étape. Une fois cette étape terminée, la transaction est soumise.

Lorsque « l'instruction de validation » est exécutée, elle inclura « l'étape de validation ».

Dans notre exemple, la transaction n'est pas explicitement démarrée, donc l'instruction de mise à jour elle-même est une transaction. Cette "étape de validation" sera utilisée lors de la validation de la transaction une fois l'exécution terminée.

Ensuite, analysons ce qui se passe lorsque MySQL redémarre anormalement à différents moments au cours de la

soumission en deux phases.

Si un crash se produit au moment A dans la figure, c'est-à-dire après avoir écrit le journal redo dans l'étape de préparation et avant d'écrire le binlog, le binlog n'a pas encore été écrit. le journal redo n'a pas encore été validé, donc lorsque le crash est restauré, la transaction sera annulée. À l'heure actuelle, le binlog n'a pas encore été écrit, il ne sera donc pas transféré vers la base de données de secours. À ce stade, nous pouvons tous comprendre.

Nous comprenons que les problèmes se produiront principalement au moment B, c'est-à-dire lorsque le binlog est écrit et qu'un crash se produit avant que le journal redo ne soit validé. Comment MySQL gérera-t-il la récupération après crash ?

Examinons d'abord les règles de jugement lors de la récupération après un crash.

1. Si la transaction dans le journal redo est terminée, c'est-à-dire qu'elle a déjà un identifiant de validation, alors soumettez-la directement

2. terminez la préparation, puis déterminez si le journal binaire de la transaction correspondant existe et est terminé :

a Si c'est le cas, validez la transaction

b.

Ici, le crash à l'instant B correspond à la situation 2(a), et la transaction sera validée pendant le processus de récupération après crash.

Maintenant, continuons à étendre la soumission en deux phases.

Question 1 : Comment MySQL sait-il que le binlog est complet ?

Réponse : Le binlog d'une transaction a un format complet :

Si vous rencontrez à la fois Prepare et Commit le redo log, soumettez-le directement

Si vous rencontrez un redo log qui n'a que parare mais pas de commit, utilisez le XID pour accéder au binlog pour trouver la transaction correspondante.

Question 3 : Le journal redo dans la phase de préparation ainsi que le binlog complet peuvent être restaurés après le redémarrage. Pourquoi MySQL est-il conçu de cette façon ?

Réponse : En fait, cette question devrait être discutée dans. la preuve par contradiction. Les données reçues sont liées à la cohérence de la sauvegarde. Au moment B, c'est-à-dire après l'écriture du binlog, MySQL plante. À ce moment-là, le binlog a été écrit et sera utilisé par la bibliothèque esclave (ou la bibliothèque restaurée à l'aide de ce binlog).

Donc, cette transaction doit également être soumise sur la base de données principale. Grâce à cette stratégie, les données de la base de données principale et de la base de données de secours sont garanties d'être cohérentes.

Question 4 : Si tel est le cas, pourquoi y a-t-il une soumission en deux étapes ? Terminez simplement d'abord d'écrire le journal de rétablissement, puis écrivez le journal binaire. Lors de la récupération après un crash, les deux journaux doivent être complets. Est-ce la même logique ?

Réponse : En fait, la validation en deux phases est un problème classique des systèmes distribués et n'est pas propre à MySQL.

Si je dois donner un scénario pour illustrer la nécessité de le faire, c'est la question de la durabilité des transactions.

Pour le moteur InnoDB, si la validation du redo log est terminée, la transaction ne peut pas être annulée (si cela permet la restauration, elle peut écraser les mises à jour d'autres transactions). Et si le journal redo est soumis directement et que le binlog ne parvient pas à être écrit, InnoDB ne peut pas revenir en arrière et les données et le binlog sont incohérents.

La soumission en deux étapes consiste à donner une chance à chacun. Quand tout le monde dit « je vais bien », soumettez ensemble.

Question 5 : Sans introduire deux logs, il n'est pas nécessaire de procéder à une soumission en deux phases. N'est-il pas suffisant d'utiliser uniquement binlog pour prendre en charge la récupération après incident et également prendre en charge l'archivage ?

Réponse : Si je traduis à nouveau cette question, cela signifie que seul le binlog est conservé, et ensuite le processus de soumission peut être modifié comme suit :... -> "Mettre à jour les données en mémoire" -> "Write binlog " -> "Commit transaction", offre-t-il également la possibilité de récupérer après un crash ?

La réponse est non.

S’il y a une raison historique, c’est qu’InnoDB n’est pas le moteur de stockage natif de MySQL. Le moteur natif de MySQL est MyISAM, qui n'a pas été conçu pour prendre en charge la récupération après incident.

Avant qu'InnoDB ne rejoigne la famille des moteurs MySQL en tant que plug-in MySQL, il s'agissait déjà d'un moteur qui assurait la récupération en cas de crash et la prise en charge des transactions.

Après la connexion d'InnoDB à MySQL, j'ai découvert que puisque le binlog n'avait pas la capacité de se remettre d'un crash, il était préférable d'utiliser le journal de rétablissement d'origine d'InnoDB.

Et si l'on parle de raisons de mise en œuvre, il y en a beaucoup. Comme mentionné dans la question, seul binlog est utilisé pour implémenter le processus de récupération après incident. J'ai dessiné un diagramme schématique et il n'y a pas de journal de rétablissement ici.

Figure 2 Seul binlog prend en charge la récupération après incident

Dans un tel processus, binlog ne peut toujours pas prendre en charge la récupération après incident. Permettez-moi de parler d'un point qui n'est pas supporté : binlog n'a pas la possibilité de restaurer des "pages de données".

Si vous êtes à la position marquée dans l'image, c'est-à-dire lorsque binlog2 a été écrit mais que la totalité de la transaction n'a pas encore été validée, MySQL plante.

Après le redémarrage, la transaction interne du moteur 2 sera annulée, puis binlog2 pourra être appliqué pour la rattraper ; mais pour la transaction 1, le système a déjà considéré la soumission terminée et n'appliquera plus binlog1 ;

Cependant, le moteur InnoDB utilise la technologie WAL Lors de l'exécution d'une transaction, la transaction est terminée après écriture dans la mémoire et dans le journal. S'il plante plus tard, comptez sur le journal pour récupérer les pages de données.

C'est-à-dire que si un crash se produit à cet endroit de la figure, la transaction 1 peut également être perdue et le niveau de la page de données sera perdu. Pour le moment, les détails de mise à jour de la page de données ne sont pas enregistrés dans le journal binaire et ne peuvent pas être restaurés.

Si vous voulez le dire, puis-je optimiser le contenu du binlog et le laisser enregistrer les modifications dans la page de données ? Oui, mais il s'agit en fait simplement de créer un autre journal de rétablissement.

Ainsi, au moins la capacité actuelle du binlog ne peut pas prendre en charge la récupération après incident.

Question 6 : Peut-il être inversé et utiliser uniquement le redo log au lieu du binlog ?

Réponse : Du point de vue de la récupération après crash, tout va bien. Vous pouvez désactiver binlog afin qu'il n'y ait pas de validation en deux phases, mais que le système soit toujours protégé contre les crashs.

Cependant, si vous examinez les scénarios d'utilisation de diverses entreprises du secteur, vous constaterez que binlog est toujours activé dans les bibliothèques de production officielles. Parce que binlog a des fonctions que le redo log ne peut pas remplacer.

L’une est l’archivage. Le journal redo est écrit en boucle. Lors de l'écriture jusqu'à la fin, vous devez revenir au début et continuer à écrire. De cette manière, le journal historique ne peut pas être conservé et le journal redo ne peut pas servir d'archive.

La première est que le système MySQL s'appuie sur binlog. Binlog est une fonction que MySQL possède depuis le début et est utilisée dans de nombreux endroits. Parmi eux, la base de la haute disponibilité du système MySQL est la réplication des journaux binaires.

Il existe également de nombreuses entreprises dotées de systèmes hétérogènes (comme certains systèmes d'analyse de données), et ces systèmes s'appuient sur la consommation du binlog MySQL pour mettre à jour leurs propres données. Si binlog est désactivé, ces systèmes en aval ne pourront pas entrer.

En bref, puisque de nombreux mécanismes système, y compris la haute disponibilité de MySQL, s'appuient désormais sur binlog, le redo log "la colombe occupant le nid de la pie" n'est pas encore possible. Vous voyez, combien il est important de développer une écologie.

Enfin, je vous recommande de faire attention à la colonne "MySQL Practical Lectures 45" de Ding Qi. Dans la colonne, Ding Qi vous aidera à trier les principales connaissances de l'apprentissage de MySQL, telles que les transactions, les index, les verrous, etc., et analysera et discutera également avec vous des problèmes spécifiques souvent rencontrés au cours du processus de développement, et vous aidera à comprendre l'essence des problèmes. Vous recevrez des explications détaillées sur la technologie et les principes de base de MySQL, ainsi qu'une analyse de 36 problèmes courants de MySQL. Le binlog au format

instruction aura COMMIT à la fin ; le binlog au format

row aura un événement XID à la fin.

De plus, après la version MySQL 5.6.2, le paramètre binlog-checksum a également été introduit pour vérifier l'exactitude du contenu du binlog. Pour les journaux binlog qui peuvent contenir des erreurs au milieu du journal en raison de problèmes de disque, MySQL peut le découvrir en vérifiant les résultats de la somme de contrôle. Par conséquent, MySQL dispose toujours d'un moyen de vérifier l'intégrité du journal binaire des transactions.

Question 2 : Quel est le lien entre le redo log et le binlog ?

Réponse : Ils ont un champ de données commun appelé XID. Lors d'une récupération après incident, le journal de rétablissement sera analysé dans l'ordre :

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!