Le principe de réalisation de l'atomicité, de la cohérence et de la durabilité des transactions

Préface

Tout le monde sait que les transactions ont quatre caractéristiques:

Atomicité

L'atomicité signifie que l'ensemble de la transaction de base de données est une unité de travail indivisible. La transaction entière est considérée comme réussie uniquement si toutes les opérations de base de données de la transaction sont exécutées avec succès. Si l'exécution d'une instruction SQL dans la transaction échoue, l'instruction SQL qui a été exécutée avec succès doit également être annulée et l'état de la base de données doit revenir à l'état avant l'exécution de la transaction.
Cohérence

La cohérence signifie qu'une transaction transforme la base de données d'un état à l'état cohérent suivant. Avant le début de la transaction et après la fin de la transaction, les contraintes d'intégrité de la base de données n'ont pas été détruites.
Isolement

L'impact d'une transaction n'est pas visible pour les autres transactions tant que la transaction n'est pas validée - ceci est obtenu par verrouillage.
Durabilité (durabilité)

Une fois la transaction validée, le résultat est permanent. Même en cas de panne, telle qu'un temps d'arrêt, la base de données peut récupérer des données.

Pour la réalisation de l'isolement, vous pouvez vous référer à cet article du mien: Une brève analyse des verrous et des transactions InnoDB

Cet article traite principalement de la manière dont les trois autres fonctionnalités sont réalisées: grâce à la restauration et à l'annulation de la base de données . Si cet article ne donne pas d'instructions spéciales, la valeur par défaut fait référence au moteur de stockage InnoDB de mysql.

atteindre

Notions de base

L'état physique de chaque page (page) change enregistré dans le journal de rétablissement
Le journal d'annulation et l'enregistrement du journal de rétablissement le journal physique n'est pas le même, il s'agit d'un journal logique. On peut considérer que lorsqu'un enregistrement est supprimé, un enregistrement d'insertion correspondant est enregistré dans le journal des annulations, et vice versa, lorsqu'un enregistrement est mis à jour, il enregistre un enregistrement de mise à jour correspondant.
LSN est appelé le numéro de séquence du journal (numéro de séquence du journal). Dans le moteur de stockage innodb, lsn occupe 8 octets. La valeur de LSN augmentera progressivement à mesure que le journal est écrit. L'opération de mise à jour dans la transaction générera un nouveau LSN. LSN existe non seulement dans le journal de rétablissement, mais existe également dans la page de données.
point de contrôle point de contrôle , ce qui signifie que lorsque des pages sales sont écrites sur le disque

Processus général

Insérez la description de l'image ici
Les journaux et les données sont modifiés dans la mémoire tampon, puis synchronisés sur le disque.

Une fois la transaction lancée, si les données modifiées ne sont pas dans le tampon du journal, elles seront lues du disque vers le tampon du journal
Avant de modifier les données de la mémoire, enregistrez les données d'origine dans le journal des annulations
Modifiez la page de données dans la mémoire, enregistrez le LSN dans la page de données de mémoire et appelez-le data_in_buffer_lsn pour le moment
Ecrivez le journal de rétablissement pour refaire le journal dans le tampon tout en modifiant la page de données (presque en même temps), et enregistrez le LSN correspondant, qui est appelé redo_log_in_buffer_lsn pour le moment;
Purge des journaux et vidage des données

Les règles de vidage des journaux sont
- Lorsque l'action de validation est émise
- Brosser une fois par seconde
- Lorsque la mémoire utilisée dans la mémoire tampon du journal dépasse la moitié
- Quand il y a un point de contrôle
Les règles de vidage des données sont
- Quand il y a un point de contrôle
Le nombre de vidages du journal est supérieur à celui du vidage des données. De plus, même pendant le point de contrôle, innoDB s'assurera ** que le journal doit être écrit avant d'écrire des données. Cette méthode est appelée enregistrement en écriture anticipée (enregistrement en écriture anticipée, WAL). ** Le moteur de stockage InnoDB garantit l'intégrité de la transaction en pré-écrivant le journal.

La raison pour laquelle la méthode du journal à écriture anticipée peut garantir l'intégrité est qu'il y a des LSN dans les pages de journal et de données, et l'ordre des enregistrements de données dans les pages de journal et de données peut être comparé via LSN. Le fichier journal est le véritable noyau.

Exemple

Source: Analyse détaillée du journal des transactions MySQL (redo log et undo log)

Insérez la description de l'image ici
Dans la figure ci-dessus, les lignes horizontales de haut en bas représentent: l'axe du temps, le LSN enregistré dans la page de données dans le tampon (data_in_buffer_lsn), le LSN enregistré dans la page de données dans le disque (data_page_on_disk_lsn), et le LSN enregistré dans le redo log dans le tampon ( redo_log_in_buffer_lsn), le LSN enregistré dans le fichier de journalisation sur le disque (redo_log_on_disk_lsn), et le LSN enregistré par le point de contrôle (checkpoint_lsn).

En supposant qu'au début (12: 0: 00), toutes les pages de journal et les pages de données ont été vidées et que le LSN du point de contrôle a également été enregistré, à ce stade, leurs LSN sont parfaitement cohérents.

Supposons qu'une transaction est lancée à ce moment et qu'une opération de mise à jour est effectuée immédiatement. Une fois l'exécution terminée, la page de données et le nouveau journal dans le tampon enregistrent la valeur LSN mise à jour, qui est supposée être 110. À ce stade, si vous exécutez show engine innodb status pour afficher la valeur de chaque LSN, c'est-à-dire l'état de position à ① sur la figure, le résultat sera:

log sequence number(110) > log flushed up to(100) = pages flushed up to = last checkpoint at

Ensuite, une instruction de suppression a été exécutée et le LSN est passé à 150. Attendez jusqu'à 12:00:01, déclenchez les règles de vidage du journal de rétablissement (dont l'une est que la fréquence de vidage du journal par défaut contrôlée par innodb_flush_log_at_timeout est de 1 seconde), puis le LSN dans le fichier de journalisation sur le disque sera mis à jour et le journal de rétablissement Le LSN de dans le tampon est le même, donc ils sont tous égaux à 150. À ce stade, afficher le statut innodb du moteur, qui est la position de ② sur la figure, se traduira par:

log sequence number(150) = log flushed up to > pages flushed up to(100) = last checkpoint at

Après cela, une instruction de mise à jour est exécutée et le LSN dans le cache passera à 300, ce qui correspond à la position de ③ sur la figure.

En supposant que le point de contrôle apparaît par la suite, qui est la position de ④ sur la figure, comme mentionné précédemment, le point de contrôle déclenchera le vidage de la page de données et de la page de journal, mais cela prend un certain temps, donc avant que le vidage de la page de données ne soit terminé, vérifiez Le LSN du point est toujours le LSN du dernier point de contrôle, mais à ce moment le LSN de la page de données et de la page de journal sur le disque a augmenté, à savoir:

log sequence number > log flushed up to 和 pages flushed up to > last checkpoint at

Cependant, la taille du journal vidé jusqu'à et des pages vidées vers ne peut pas être déterminée, car le vidage du journal peut être plus rapide que le vidage des données, ou il peut être égal ou plus lent. Cependant, le mécanisme de point de contrôle protège que la vitesse de vidage des données est plus lente que le vidage du journal: lorsque la vitesse de vidage des données dépasse le vidage du journal, le vidage des données sera temporairement arrêté et attendra que la progression du vidage du journal dépasse le vidage des données.

Lorsque la page de données et la page de journal sont vidées, c'est-à-dire lorsque la position ⑤ est atteinte, tous les LSN sont égaux à 300.

Au fil du temps, il atteint 12:00:02, qui est la position ⑥ sur la figure, ce qui déclenche la règle de vidage du journal, mais à ce stade, le journal LSN dans le tampon est le même que le journal LSN dans le disque, donc le vidage du journal n'est pas effectué. Disque, c'est-à-dire que tous les lsns sont égaux dans l'état de show engine innodb à ce moment.

Ensuite, une instruction d'insertion est exécutée, en supposant que le LSN dans le tampon a augmenté à 800, qui est la position ⑦ sur la figure. À ce stade, la taille et la position des différents LSN sont les mêmes.

Exécution ultérieure de l'action de soumission, c'est-à-dire position ⑧. Par défaut, l'action de soumission déclenchera le vidage du journal, mais ne déclenchera pas le vidage des données, donc le résultat de l'état innodb de show engine est:

log sequence number = log flushed up to > pages flushed up to = last checkpoint at

Enfin, avec le temps, le point de contrôle est réapparu, c'est-à-dire la position ⑨ sur la figure. Cependant, ce point de contrôle ne déclenchera pas le vidage du journal, car le LSN du journal a été synchronisé avant le point de contrôle. En supposant que la vitesse de clignotement des données est extrêmement rapide cette fois, elle sera terminée dans un instant et le changement d'état ne peut pas être capturé, alors le résultat du statut innodb de show engine sera le même LSN.

restaurer

La stratégie de récupération de mysql est:

Lors de la récupération, recommencez d'abord toutes les transactions conformément à redo, y compris les transactions non validées
Ensuite, annulez les transactions non validées en fonction de l'annulation.

Grâce à cette stratégie, l'atomicité, la cohérence et la pérennité de la transaction sont garanties.

De plus, le mécanisme de point de contrôle est introduit et lors de la restauration, il vous suffit de restaurer à partir de la position du point de contrôle.

Impressions

De nombreux contenus sur Internet peuvent être inexacts. Même cet article que j'ai écrit peut être inexact. La meilleure façon de résoudre ce problème est de lire le code source.
Différentes techniques peuvent aboutir à des résultats différents, mais les principes fondamentaux sont souvent liés, et ces principes fondamentaux sont généralement construits sur la base de connaissances sur
L'apprentissage des connaissances peut apprendre différentes profondeurs. Après avoir lu " MySQL Technical Insider: InnoDB Storage Engine ", vous pouvez obtenir une compréhension générale de l'utilisation de mysql, mais la compréhension n'est pas approfondie. Avec la rédaction de ces deux articles, la compréhension de MySQL est plus approfondie Certains, si vous avez besoin d'aller plus loin, vous devez vraiment regarder le code source. Cette chose semble prendre plus de temps. Par conséquent, vous devez savoir quel niveau vous devez comprendre et utiliser un temps limité pour faire des choses plus rentables . Le choix est très important.

Les données

Etude approfondie des transactions MySQL: le principe de réalisation des fonctionnalités ACID
Analyse détaillée des journaux de transactions MySQL (redo log et undo log)
https://blog.csdn.net/suerge_storm/article/details/90484944
https://blog.csdn.net/qq_41151659/article/details/99559397

Enfin

Si vous aimez mon article, vous pouvez suivre mon compte public (Programmeur Mala Tang)

Revue des articles précédents: