Un guide complet des journaux MySQL

Cet article vous apporte des connaissances pertinentes sur mysql, qui présente principalement des problèmes liés aux journaux. Le système de journalisation de Mysql est la clé pour garantir que les données ne seront pas perdues, peu importe le moment où Mysql plante.

Apprentissage recommandé : Tutoriel vidéo MySQL

Le système de journalisation de MySQL est la clé de Mysql garantissant que les données ne seront pas perdues, peu importe le moment où il plante

Comme nous le savons tous, Mysql est une base de données persistante, et tout les données sont persistantes sur le disque dur, garantissant que les données ne seront pas perdues

Mysql garantit que les données ne seront pas perdues sous les deux aspects suivants

• Il peut restaurer l'état des données à tout moment

• Non avant ou après la soumission de la transaction Après un crash, les données ne seront pas perdues

Un crash pendant la transaction peut être restauré à l'état avant la soumission de la transaction

Après la soumission de la transaction, les données soumises seront ne soyez pas perdu

La clé pour que MySQL garantisse les deux points ci-dessus est d'utiliser undo Log, redo log et binlog sont implémentés par trois journaux. Ensuite, nous présenterons un par un

undo log rollback log

undo log est le. journal de restauration de Mysql, qui stocke l'ancienne version des données

La fonction principale

Stockage de l'ancienne version des données

Fonctionne avec la vue en lecture et les champs cachés pour implémenter la lecture des instantanés Mysql

Utilisé pour revenir au version avant le début de la transaction lorsque l'exécution de la transaction échoue

Quels types de journaux d'annulation existe-t-il ?

Le journal d'annulation a deux types

Pour la commande d'insertion, le journal d'annulation enregistre la clé primaire de l'enregistrement nouvellement ajouté pendant. rollback, vous pouvez supprimer l'enregistrement correspondant en fonction de la clé primaire dans le journal d'annulation

Pour la commande update/delete, le journal d'annulation enregistre les anciennes données de l'enregistrement modifié

Chaque ligne de données dans Mysql a deux champs : l'ID de transaction de la dernière ligne de données actuelle modifiée et le pointeur de restauration Lorsque la ligne de données est modifiée. Après cela, le pointeur du journal d'annulation pointe vers l'ancienne ligne de données et le pointeur de restauration de la ligne de données nouvellement générée pointe vers l'ancienne. ligne de données actuellement pointée par le pointeur de journal d'annulation

• Mysql afin d'éviter que le pointeur de journal d'annulation ne modifie le pointé. Lorsque des problèmes de concurrence surviennent, un verrou exclusif sera ajouté au pointeur de journal d'annulation avant modification pour garantir l'écriture correcte de le journal d'annulation

undo log Quand supprimer

undo log est utilisé pour garantir que la transaction est Lorsqu'elle n'est pas soumise, elle peut être facilement restaurée à l'état avant le début de la transaction . Lorsque la transaction est soumise, le journal d'annulation perd sa fonction et doit être supprimé. Le journal d'annulation est supprimé par le thread Puration dans Mysql. Vérifiez l'indicateur delete_bit dans le journal d'annulation. défini sur true une fois la transaction validée. Lorsque le thread de purge trouve un enregistrement qui est vrai, il sera responsable de sa suppression

redo log redo log

redo log est le journal physique de Mysql Responsable de l'enregistrement de quel type de. les opérations sont effectuées sur une certaine page de données

Le rôle du redo log

Responsable de l'enregistrement de la modification des données par les transactions soumises Le contenu enregistré est probablement le décalage z de la page y de la table x Une mise à jour. a été conçu
pour que Mysql n'ait pas besoin d'attendre le disque de persistance des données lors de la validation d'une transaction, et n'ait besoin que de conserver le journal de rétablissement sur le disque
Le nombre de journaux de rétablissement non effacés indique que le disque n'a pas été vidé Le nombre de pages sales
Pourquoi choisissez-vous de conserver le journal de rétablissement lors de la soumission d'une transaction, au lieu de conserver les données sur le disque

La persistance des données sur le disque est un processus d'E/S aléatoire, donc Mysql choisit de mettre en cache le données et attendez une opportunité appropriée Écrivez les données sur le disque immédiatement pour réduire les E/S

Cependant, il existe un risque de perte de cache de données en mémoire, donc Mysql choisit de persister le journal de rétablissement

le journal de rétablissement est écrit séquentiellement, et l'efficacité de la persistance est supérieure à celle de l'écriture aléatoire. , et le journal redo enregistre les modifications apportées aux données. Tant que le journal redo est là, les données peuvent être restaurées après le redémarrage de Mysql

Dans InnoDB, le journal redo est un fichier fixe. taille d'existence semblable à une file d'attente circulaire, et chaque écriture est effectuée à partir de l'arrière. La position d'écriture, lorsque les données sont persistantes, déplacez le point de contrôle pour lire vers l'avant

La raison de cette conception est que le journal de rétablissement existe pour empêcher les données de la page sale mises en cache ne sont pas perdues après le crash de Mysql

Lorsque Mysql Une fois les données conservées sur le disque, la partie persistante du journal de rétablissement est en fait inutile et de l'espace peut être créé pour enregistrer de nouvelles données

Le différence entre annuler le journal et refaire le journal

Le journal d'annulation enregistre l'état des anciennes données pendant l'exécution de la transaction et le journal de restauration enregistre l'état après la mise à jour des données.

Le journal de restauration garantit en fait la durabilité et la cohérence des transactions, tandis que le journal d'annulation garantit l'atomicité des transactions.

binlog est un journal implémenté par la couche serveur Mysql. Il est commun à tous les moteurs.

Fonction

binlog enregistre la logique d'instruction originale de MySQL et est enregistrée sous forme d'écriture d'ajout. utilisé pour restaurer l'état des données de la base de données MySQL à tout moment

Donc binlog est appelé un journal d'archive

En même temps, binlog est également une dépendance de Mysql pour implémenter la réplication maître-esclave. La bibliothèque esclave synchronise la bibliothèque principale. bibliothèque en copiant la lecture du journal binaire à partir de la bibliothèque principale. L'état des données

définition

écrit d'abord le journal sur le disque, puis écrit les données sur le disque. L'opération d'écriture de Mysql n'est pas écrite sur le disque. immédiatement, mais le journal est écrit en premier pour garantir que le redo log et le binlog sont persistants sur le disque, puis le thread d'arrière-plan choisit l'heure de persistance des données sur le disque dur

Pourquoi devons-nous écrire le journal sur le disque en premier

Parce que le vidage des pages sales est un processus de lecture et d'écriture aléatoire, persistant sur le disque. La vitesse n'est certainement pas aussi rapide que le redo log | binlog. choisissez l'opportunité de le conserver de manière asynchrone sur le disque à un stade ultérieur

Ainsi, avant que les pages sales ne soient vidées sur le disque, pendant cette période, redo log | binlog assure la persistance des données et empêche la perte de données dans la mémoire lors de pannes de courant. et redémarre. Lorsque les pages sales sont pleines, les pages sales doivent être écrites sur le disque puis éliminées. Pourquoi pas toutes les éliminer, puis les restaurer via le journal de rétablissement la prochaine fois qu'elles seront utilisées ? performances, si les données doivent être comparées et mises à jour avec le journal redo à chaque fois qu'elles sont lues du disque vers la mémoire, l'efficacité est très faible

Brosse MySQL L'écriture de pages sales sur le disque garantit que tant que la page de données est dans la mémoire, les dernières données peuvent être renvoyées. S'il n'y a pas de données dans la mémoire, vous pouvez certainement obtenir les dernières données correctes en les lisant à partir du disque sans avoir à refaire la comparaison du journal. processus d'écriture du binlog et du redo log - la garantie de base du mécanisme WAL

Le binlog et le redo log divisent l'écriture du journal en trois processus : écriture du cache, écriture et synchronisation

Pendant l'exécution de la transaction Pendant le processus, le binlog et le redo log seront écrit dans le cache alloué correspondant, afin qu'ils puissent être écrits sur le disque en même temps que la transaction est soumise, l'écriture sera d'abord effectuée pour écrire les données sur la page du système d'exploitation dans le cache. les données n'ont pas été réellement écrites dans le fichier pour le moment, mais elles ont été transférées dans le cache du système d'exploitation pour être conservées. Si le processus Mysql plante à ce moment-là, cette partie des données écrites ne sera pas perdue. et le thread du noyau du système d'exploitation sera responsable. Écrivez cette partie des données dans le cache sur le disque

Mais si le système d'exploitation plante, cette partie des données sera perdue

Enfin, mysql appelle manuellement sync pour conserver les données écrites dans le cache de pages sur le disque dur. Une fois l'écriture terminée, les données sont conservées avec succès

Les étapes finales d'écriture et de synchronisation, mysql fournit les paramètres correspondants pour contrôler la stratégie d'écriture

redo. log est contrôlé par innodb_flush_log_at_trx_commit

• Lorsqu'il est défini sur 0 , ce qui signifie que chaque fois qu'une transaction est soumise, le journal redo n'est laissé que dans le cache du journal redo. Le risque de perte est le plus grand lorsqu'il est défini sur 1. signifie que chaque fois qu'une transaction est soumise, le journal redo est directement conservé sur le disque

Le risque de perte est minime, mais l'utilisation des E/S est importante

Lorsqu'il est défini sur 2, cela signifie qu'à chaque fois qu'une transaction est soumise est soumis, le journal redo est uniquement écrit dans le cache de la page

L'utilisation des IO est centrée et l'écriture est Le processus le plus consommateur d'IO du disque est laissé au système d'exploitation. Le binlog est contrôlé par le paramètre. sync_binlog. Lorsque sync_binlog=0, cela signifie que chaque fois qu'une transaction est soumise, seule l'écriture est effectuée, pas fsync.

• sync_binlog= Lorsque 1, cela signifie que fsync sera exécuté à chaque fois qu'une transaction est soumise. =N(N>1), cela signifie que l'écriture sera effectuée à chaque fois qu'une transaction est soumise, mais fsync sera exécuté une fois que N transactions auront été accumulées. Soumettre

Qu'est-ce que la soumission du journal en deux étapes

• .
Le processus de soumission du journal redo est divisé en deux étapes : préparer et valider. La soumission du journal Binlog se situe au milieu de ces deux étapes

Lorsqu'une transaction est soumise, le journal redo vient en premier. Après la soumission, elle entre dans l'état de préparation et puis une fois la soumission du binlog terminée, le journal redo peut changer le statut du journal pour valider soumis

• Pourquoi la soumission du journal en deux étapes est requise

Cela est lié au mécanisme de restauration du moteur redo d'InnoDB. a été soumis La transaction ne peut pas être annulée. Si l'écriture du journal binaire échoue après la soumission du journal redo, il y aura deux incohérences. Si la base de données redémarre anormalement à ce moment-là, il vaut la peine de réfléchir à celle qui doit être utilisée. restaurer les données, donc seules deux étapes de soumission du journal sont requises

Supposons que la base de données plante au moment A, car le journal binaire n'a pas été écrit et le journal redo n'a pas été soumis, donc la transaction sera annulée après le redémarrage et les deux journaux seront toujours dans le même état

Si. c'est la période B, vous devez la corriger. L'indicateur de validation du journal redo est jugé. Vérifiez s'il y a un indicateur de validation dans le journal redo. S'il y a un indicateur de validation, la transaction sera soumise directement. s'il n'y a pas d'indicateur de validation de la transaction correspondante dans le journal redo, le binlog sera vérifié

• Si le binlog est complet et a l'indicateur de validation, la transaction sera soumise et l'indicateur de validation sera ajouté après le journal redo. . Si le binlog est incomplet, la transaction sera annulée

• Ici, vous pouvez constater qu'un crash s'est produit lors de la soumission du journal en deux phases. Le jugement standard est basé sur le binlog. La raison en est que la réplication maître-esclave est. basé sur binlog. Si l'intégrité des deux journaux doit être vérifiée, le temps de passage à la bibliothèque esclave après le blocage de la bibliothèque principale deviendra plus long. Binlog À titre de référence, si la base de données principale est en panne, utilisez simplement le binlog pour. restaurer les données de la base de données esclave. Il n'est pas nécessaire de vérifier l'intégrité du redo log

De plus, binlog est un journal commun pour la couche Mysql Server, ce qui est également la raison pour laquelle binlog est choisi comme référence

Deux inconvénients de la soumission des journaux d'étape

Temps d'E/S disque élevés

Lors de la soumission des journaux, il y aura des opérations de vidage correspondant au redo log et au binlog. Le nombre d'IO est élevé
Concurrence féroce pour les verrous.

Pour garantir que lorsque plusieurs transactions sont soumises, les enregistrements du journal sont cohérents avec l'ordre de soumission des transactions, des verrous seront utilisés pour garantir l'ordre relatif des soumissions des journaux

• Mais les performances se détérioreront lorsque le niveau de concurrence est large

Mécanisme de soumission de groupe

Le rôle du mécanisme de soumission de groupeLorsque la soumission de transactions est évitée, les journaux de plusieurs transactions sont fusionnés pour écrire, réduisant ainsi les opérations d'E/S sur disque

Mise en œuvre du mécanisme de soumission de groupe

Le mécanisme de soumission de groupe divise le processus de validation en trois processus, maintient une file d'attente pour chaque processus et utilise des verrous pour garantir l'ordre d'écriture des transactions

La division des verrous en trois étapes peut réduire la granularité du verrouillage, sans verrouiller l'ensemble du processus de soumission de la transaction

Lorsque la file d'attente est vide, la première transaction entrant dans la file d'attente deviendra le leader des transactions suivantes, conduisant les transactions suivantes à terminer la phase suivante des opérations

• Phase 1 : Phase de vidage : plusieurs transactions écrivent le binlog du cache vers le fichier dans l'ordre d'entrée (sans vider le disque)

La première transaction à entrer dans la phase de vidage servira de leader pour diriger les transactions suivantes

Leadership La transaction amènera toutes les transactions à écrire + fsync dans le journal redo, c'est-à-dire à écrire le journal redo sur le disque et à terminer la phase de proposition du journal redo

Si Mysql plante à ce stade, cet ensemble de transactions sera annulé après le redémarrage flush阶段 : 多个事务按进入的顺序将binlog从cache中写入文件 (不刷盘)

第一个进入flush阶段的事务会作为领导者领导后面进入的事务

领导者事务会带领所有的事务对 redo log 进行一次 write + fsync, 也就是将redo log 写入磁盘, 完成redo log 的propare阶段

如果在这个阶段Mysql崩溃了, 会在重启后回滚这组事务

阶段二 : sync : 对binlog文件做fsync操作 (将多个事务的binlog合并一起刷盘)

在flush阶段将binlog写入到binlog文件后, 会等待一段时间再进行刷盘, 目的是组合更多事务的binlog一起刷盘减少消耗

等待会有时间限制和最大事务限制, 满足其中一个条件就会立刻对binlog进行刷盘

sync阶段主要负责binlog的组提交, 如果当前阶段Mysql崩溃的话, 在重启后可以通过redo log的刷盘记录继续完成事务提交

• 因为此时binlog已经完成提交了, 所以可以根据redo log来继续提交事务

阶段三 : commit

Phase 2 : sync : Effectuer une opération fsync sur le fichier binlog (fusionner les binlogs de plusieurs transactions et vider le disque ensemble)

Après avoir écrit le binlog dans le fichier binlog dans la phase de vidage, il attendra un certain temps. Ensuite, videz le disque, le but est de combiner le journal binaire de plusieurs transactions et de vider le disque ensemble pour réduire la consommation.

Il y aura un délai et une limite maximale de transaction pour l'attente. . Si l'une des conditions est remplie, le binlog sera vidé immédiatement🎜🎜L'étape de synchronisation est principalement responsable de la soumission du groupe binlog, si Mysql plante à l'étape actuelle, vous pouvez continuer à terminer la soumission de la transaction via le vidage du journal redo. enregistrer après le redémarrage🎜🎜🎜🎜Étant donné que le binlog a terminé la soumission à ce moment-là, vous pouvez continuer à soumettre la transaction selon le journal redo🎜🎜🎜 🎜Troisième étape : commit : effectuez l'opération de validation InnoDB sur chaque transaction🎜🎜Apprentissage recommandé : 🎜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!