Introduction au journal MySQL, au journal redo et au binlog

Recommandations d'apprentissage gratuites : tutoriel vidéo mysql

Avant-propos

Tant que vous êtes un programmeur ayant été exposé à MySQL, vous avez plus ou moins entendu parler de redo log (redo log) et de binlog (archive log ). Aujourd’hui, partageons les utilisations et les différences entre ces deux journaux.

Pour faire simple, le redo log est un journal unique à InnoDB Si d'autres moteurs de stockage sont utilisés, il n'y a pas de redo log, seulement du binlog.

Binlog est le journal de la couche serveur de MySQL Quel que soit le moteur de stockage utilisé, il y aura binlog. Alors, pourquoi avons-nous besoin de redo log et binlog ? Tout ne peut-il pas être résolu avec un seul binlog ? Examinons ensuite en détail la différence entre redo log et binlog.

redo log

Dans MySQL, si vous souhaitez mettre à jour une instruction, vous devez inclure des conditions de mise à jour, telles que update T set name = 'god -jiang' où id=6, généralement l'instruction avec id=6 est interrogée en premier, puis l'opération de mise à jour est effectuée.

Si le nombre de mises à jour est de 100, 1 000 ou même 10 000, chaque mise à jour doit être écrite sur le disque. Ensuite, l'enregistrement correspondant doit être trouvé sur le disque puis mis à jour. Le coût d'E/S et de recherche de l'ensemble du processus est trop élevé. Afin de résoudre ce problème, les concepteurs de MySQL ont utilisé la technologie WAL pour le résoudre. Le nom complet de WAL est Write Ahead Logging, ce qui signifie écrire d'abord le journal, puis écrire sur le disque.

Opération spécifique : lorsqu'un enregistrement doit être mis à jour, le moteur InnoDB écrira d'abord l'enregistrement dans le journal redo et mettra à jour la mémoire. À ce moment, la mise à jour est terminée. Dans le même temps, le moteur InnoDB mettra à jour cet enregistrement d'opération sur le disque au moment approprié (lorsque le système est inactif). Cette mise à jour a souvent lieu lorsque le système est relativement inactif.

Mais la taille du redo log est fixe, et il est impossible d'écrire à l'infini tout le temps. Voyons comment MySQL fait.

write pos est la position de l'enregistrement actuel, reculant lors de l'écriture. Le point de contrôle est la position actuelle à effacer, qui recule également et circule. Avant d'effacer l'enregistrement, l'enregistrement doit être mis à jour dans le fichier de données.

La partie verte entre write pos et check point indique que de nouvelles opérations peuvent être enregistrées. Si la position d'écriture rattrape le point de contrôle, cela signifie que le journal de rétablissement est plein. À ce stade, les nouvelles opérations ne peuvent pas être poursuivies. Vous devez arrêter d'effacer certains enregistrements et repousser le point de contrôle.

Avec le redo log, InnoDB peut garantir que même si la base de données détecte une exception et redémarre, les transactions précédemment soumises ne seront pas perdues. Cette fonctionnalité est également appelée crash-safe.

Ce qui précède est l'introduction au redo log. Après l'avoir lu, vous pouvez essayer de demander aux collègues DBA de votre entreprise si MySQL peut être restauré à l'état d'une seconde dans un délai d'un demi-mois. , tout cela grâce au redo log.

binlog

En regardant MySQL dans son ensemble, il est en fait divisé en deux couches, l'une est la couche serveur et l'autre est la couche moteur de stockage. Le redo log discuté ci-dessus est un journal unique au moteur InnoDB, tandis que le binlog est un journal appartenant à la couche serveur, également appelé journal d'archive.

La différence entre redo log et binlog

• redo log est unique au moteur InnoDB binlog est implémenté par la couche serveur de MySQL et peut être utilisé ; par tous les moteurs
• Le redo log est un journal physique, qui enregistre "XXX modifications ont été apportées sur la page de données XXX" ; le binlog est un journal logique, qui enregistre la logique d'origine, et son enregistrement est le correspondant ; Instruction SQL
• Le journal redo est écrit en boucle et l'espace sera certainement épuisé, donc la position d'écriture et le point de contrôle doivent correspondre. Le journal binaire est écrit en plus et il passera au suivant lorsqu'il sera exécuté ; atteint une certaine taille et n'écrasera pas le journal précédent

Démontrer le processus interne de l'exécuteur et du moteur InnoDB via une simple instruction de mise à jour

update T set name = 'god-jiang' where id = 6

1. Récupérez l'enregistrement avec l'id=6 du moteur InnoDB via l'exécuteur, puis chargez-le en mémoire
2. L'exécuteur obtient le résultat renvoyé par le moteur, change le nom en 'god-jiang', puis appelle à nouveau l'interface du moteur de stockage pour écrire de nouvelles données
3. Le moteur met à jour les nouvelles données dans la mémoire et écrit cette opération de mise à jour dans le journal redo. À ce moment, le journal redo est dans l'état de préparation. .
4. L'exécuteur génère le binlog de cette opération et écrit le binlog sur le disque
5. L'exécuteur appelle le moteur Soumettez l'interface de transaction et modifiez le journal redo qui vient d'être écrit à l'état de validation. La mise à jour est terminée

et l'organigramme correspondant

Enfin, pourquoi l'écriture dans le journal de rétablissement le met-elle dans la préparation état, puis écrire dans le journal binaire change l'état de validation ? En fait, ce processus est appelé « soumission en deux étapes ».

Soumission en deux phases

En fait, le redo log et le binlog peuvent être utilisés pour représenter l'état de la soumission de la transaction, et la soumission en deux phases consiste à les conserver deux états logiquement cohérents.

Par exemple : update T set name = 'god-jiang' Where id = 6Que se passera-t-il sans validation en deux phases ?

Écrivez d'abord le redo log, puis le binlog. Supposons qu'après avoir écrit le journal redo, le binlog n'a pas encore été écrit et que MySQL redémarre anormalement à ce moment-là. Parce que le journal redo a été écrit, name = 'god-jiang' lors de la restauration du système. Cependant, le journal binaire n'a pas été écrit, donc le journal binaire n'enregistre pas cette instruction à ce moment-là. Lorsque le journal binaire est utilisé pour restaurer des données à ce moment-là, le nom restauré est la valeur d'origine, qui est différente de celle du journal redo.

De même, si vous écrivez d'abord binlog puis refaites un journal, vous constaterez également que les données récupérées par les deux journaux sont différentes. Cette incohérence entraînera une incohérence maître-esclave en ligne.

Résumé

• Le journal redo peut enregistrer des fonctionnalités de sécurité en cas de crash et garantir que les données de redémarrage anormal de MySQL ne seront pas perdues
• Le binlog peut enregistrer les instructions SQL correspondantes peut également garantir que les données ne seront pas perdues en cas de redémarrage anormal de MySQL
• La soumission en deux étapes de la transaction peut maintenir la cohérence logique des données

Recommandations d'apprentissage gratuites associées :base de données mysql(vidéo)

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!