Intervieweur : Parlons du mécanisme de soumission en deux phases de MySQL.

Cet article vous amènera à comprendre le mécanisme de soumission en deux phases de MySQL, à présenter le journal redo et le journal bin et à voir comment ils coopèrent pour terminer la soumission en deux phases. J'espère que cela sera utile à tout le monde !

MySQL garantit la cohérence logique du journal redo et du journal bin grâce au mécanisme de soumission en deux étapes, garantissant ainsi que les données ne sont pas perdues et que les données de la base de données maître-esclave sont cohérentes.

En parlant de soumission en deux étapes, nous devons d'abord introduire le redo log et le bin log.

redo log

redo log est le redo log, qui est un journal unique au moteur InnoDB (certains intervieweurs posent souvent des questions à ce sujet).

Que fait principalement le redo log ?

Prenons l'exemple de la mise à jour des données. Nous savons que les données MySQL sont stockées sur le disque si chaque fois que les données sont mises à jour, le disque est recherché pour trouver les données à mettre à jour. Si l'opération de mise à jour est effectuée, le coût d'E/S. sera très élevé.

C'est bien s'il s'agit d'un disque SSD, mais s'il s'agit d'un disque dur mécanique, les performances de mise à jour de MySQL ne peuvent tout simplement pas répondre aux besoins de notre entreprise.

Ainsi, MySQL utilise une technologie appelée WAL, Write-Ahead Logging.

Lors de la mise à jour des données, l'opération de mise à jour (c'est-à-dire les modifications apportées à une certaine page de données) est d'abord écrite dans le journal redo, puis la mémoire est mise à jour. Cette opération de mise à jour est terminée. MySQL videra les enregistrements d'opérations de rétablissement sur le disque lorsque le serveur est inactif pour maintenir la cohérence des données.

Il est à noter que bien que le redo log soit également un fichier sur le disque, les performances sont très élevées car l'opération est écrite de manière séquentielle.

Bien sûr, le journal redo a également une limite de taille, et une écriture illimitée est impossible.

Prenons l'image ci-dessus comme exemple. Quatre journaux de rétablissement sont configurés. La position d'écriture représente l'endroit où l'enregistrement actuel est écrit, et le point de contrôle représente un point d'avancement. . opération pour garantir que le journal redo peut être écrit en continu.

Bien sûr, avant d'effacer les données, les enregistrements du journal redo seront vidés sur le disque.

Grâce au redo log, vous pouvez vous assurer que même si MySQL redémarre anormalement, les données ne seront pas perdues (car le redo log est un journal physique et peut être relu. Cette fonctionnalité est appelée crash-safe).

bin log

bin log est un journal fourni par MySQL Server, appelé journal d'archive Tous les moteurs peuvent utiliser le journal bin.

Quelle est la différence entre le journal bin et le journal redo ?

1. Les fournisseurs de ces deux journaux sont différents : le journal bin est fourni par le serveur MySQL et le journal redo est unique au moteur InnoDB.

2. Le journal redo enregistre principalement les modifications apportées à une certaine page de données. Le journal bin enregistre la logique originale de l'instruction, comme la mise à jour d'un certain champ d'une certaine ligne.

3. Le redo log est écrit en boucle et les données seront écrasées. Le journal du bac est ajouté lorsqu'un fichier est plein, le fichier suivant est écrit.

Soumission en deux phases

Après avoir présenté le journal redo et le journal bin, examinons comment ils coopèrent pour terminer la soumission en deux phases.

L'image ci-dessus est un processus de mise à jour des données. Vous pouvez voir qu'avant de mettre à jour une donnée, MySQL chargera d'abord les données dans la mémoire, puis mettra à jour la mémoire et commencera à écrire un journal de rétablissement.

À ce stade, le journal redo est à l'état de préparation. Une fois l'écriture du journal bin terminée, puis la transaction soumise, l'opération de mise à jour de cet enregistrement est terminée.

redo log prepare -> write bin log -> redo log commit, ce processus est appelé validation en deux étapes.

Analysons les avantages de l'utilisation de la soumission en deux étapes.

Scénario 1 : lorsque le journal redo est à l'état de préparation, si l'écriture dans le journal bin échoue, la mise à jour échoue. À ce stade, le journal redo n'a pas de validation et le journal bin n'a aucun enregistrement. est conforme et il n'y a aucun problème.

Scénario 2 : lorsque le journal redo est à l'état de préparation, le journal bin est écrit avec succès, mais l'ordinateur est en panne et la validation échoue. À ce moment-là, le journal bin a généré un enregistrement, le journal redo n'a pas été écrit correctement et les données étaient temporairement incohérentes.

Mais ne vous inquiétez pas, lorsque MySQL redémarrera, il vérifiera les enregistrements à l'état de préparation dans le journal de rétablissement. Dans le redo log, un champ appelé En fait, si l'écriture échoue, la soumission sera abandonnée.

Grâce à ce mécanisme, la cohérence du redo log et du bin log est assurée.

Résumé

La raison pour laquelle il existe à la fois un journal redo et un journal bin dans MySQL est que le journal bin est un journal d'archive fourni par le serveur MySQL et n'a pas lui-même de fonctionnalités de sécurité en cas de crash. Le journal redo lui-même n'a pas la capacité d'archiver. Il s'agit d'un journal écrit en boucle.

MySQL assure la cohérence des données en intégrant ces deux logs et en utilisant un mécanisme de soumission en deux étapes.

Écrire n'est pas facile, merci pour vos likes et votre attention.

【Recommandation associée : tutoriel vidéo mysql】

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!