Analyse des opérations de rétablissement et d'annulation dans les transactions MySQL (image et texte)

Le contenu de cet article concerne l'analyse (images et texte) des opérations de restauration et d'annulation dans les transactions MySQL. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer.

Nous savons tous que les transactions ont 4 caractéristiques : l'atomicité, la cohérence, l'isolement et la durabilité. Toutes les opérations dans une transaction sont soit effectuées, soit pas du tout. L'isolation des transactions est obtenue par le mécanisme de verrouillage, et l'atomicité, la cohérence et la durabilité sont garanties par le journal redo et l'annulation de la transaction. Cet article abordera donc plusieurs problèmes liés au rétablissement et à l'annulation des transactions :

• Que sont les journaux de rétablissement et les journaux d'annulation ?

• Comment redo assure-t-il la pérennité des transactions ?

• L'annulation du journal est-elle le processus inverse du rétablissement du journal ?

redo log

Type de Redo

Redo log est utilisé Garantir la durabilité du transaction, qui est le D dans la transaction ACID. En fait, il peut être divisé en deux types suivants :

• Journal de rétablissement physique

• Journal de rétablissement logique

Dans le moteur de stockage InnoDB, dans la plupart des cas, Redo est un journal physique, enregistrant les modifications physiques des pages de données . Le journal redo logique n'enregistre pas la modification réelle de la page, mais enregistre un type d'opération qui modifie la page. Par exemple, lors de la création d'une nouvelle page de données, un journal logique doit être enregistré. Concernant le Redo log logique, il s'agit davantage de contenu de bas niveau. Ici, il suffit de rappeler que dans la plupart des cas, Redo est un journal physique des opérations de modification DML sur la page qui doit être enregistré.

Le rôle. de Redo

La fonction principale du journal Redo est la récupération après incident de la base de données

La composition du journal Redo

Le journal Redo peut être simplement divisé en deux parties suivantes :

• Le premier est le tampon de journalisation en mémoire, qui est volatile. Dans la mémoire

• Le second est le fichier de journalisation ), est persistant. et est enregistré sur le disque

Quand écrire Redo

L'image ci-dessus reflète simplement le processus d'écriture de Redo. Voici plus de détails Parlons du timing de Redo. écriture de rétablissement :

• Une fois la modification de la page de données terminée et avant que la page sale ne soit vidée du disque, le journal de rétablissement est écrit. Notez que les données sont d'abord modifiées, puis le journal est écrit

• le journal redo est réécrit sur le disque avant la page de données

• agrégation Les modifications apportées aux index, aux index secondaires et aux pages d'annulation doivent toutes être enregistrées dans les journaux de rétablissement.

Le processus global de Redo

Ce qui suit prend une transaction de mise à jour comme exemple pour appréhender le processus de flux de redo log d'un point de vue macro, comme le montre la figure suivante :

• Étape 1 : Lisez d'abord les données originales du disque dans la mémoire et modifiez la copie mémoire du data

• Étape 2 : Générez un journal redo et écrivez-le dans le tampon redo log, qui enregistre la valeur modifiée des données

• Étape 3 : Lorsque la transaction est validée, actualisez le contenu du tampon de journalisation dans le fichier de journalisation et utilisez l'écriture d'ajout dans le fichier de journalisation

• Étape 4 : Actualisez régulièrement le fichier modifié les données en mémoire sur le disque

Comment redo assure-t-il la pérennité des transactions ?

InnoDB est un moteur de stockage de transactions. Il atteint la durabilité des transactions grâce au Mécanisme Forcer le journal à la validation, c'est-à-dire que lorsqu'une transaction est validée, le tampon de journalisation est d'abord écrit dans le journal de rétablissement. log. La persistance n'est pas terminée tant que l'opération de validation de la transaction n'est pas terminée. Cette approche est également appelée Write-Ahead Log (persistance pré-log) Avant de conserver une page de données, la page de journal correspondante est conservée en mémoire.

Afin de garantir que chaque journal est écrit dans le fichier de journalisation, après chaque fois que le tampon de restauration est écrit dans le fichier de journalisation, par défaut, le moteur de stockage InnoDB doit appeler un fsync opération ,Étant donné que le journal redo est ouvert sans l'option O_DIRECT, le journal redo est d'abord écrit dans le cache du système de fichiers. Afin de garantir que le journal redo est écrit sur le disque, une opération fsync doit être effectuée. fsync est une opération d'appel système. L'efficacité de fsync dépend des performances du disque. Par conséquent, les performances du disque affectent également les performances de soumission des transactions, c'est-à-dire les performances de la base de données.
(L'option O_DIRECT est une option du système Linux. Après avoir utilisé cette option, le fichier sera directement exploité par IO et écrit directement sur le disque sans passer par le cache du système de fichiers)

Ci-dessus Le Force Log at Commit mentionné est contrôlé par le paramètre innodb_flush_log_at_trx_commit fourni par le moteur de stockage InnoDB. Ce paramètre peut contrôler la stratégie de vidage du journal redo sur le disque. permettre également aux utilisateurs de définir des situations non persistantes, comme suit :

• Lorsque le paramètre est défini sur 1 (la valeur par défaut est 1), cela signifie que l'opération fsync doit être appelé une fois lorsque la transaction est validée, ce qui est la configuration la plus sûre pour garantir la durabilité

• Lorsque le paramètre est défini sur 2, seule l'opération write est effectuée lorsque la transaction est soumise, ce qui garantit uniquement que le tampon de journalisation est écrit dans le cache des pages du système. , et aucune opération fsync n'est effectuée. , donc si la base de données MySQL tombe en panne, la transaction ne sera pas perdue, mais le système d'exploitation peut tomber en panne

• Lorsque le paramètre est défini sur. 0, cela signifie que redo ne sera pas écrit lorsque la transaction est soumise. Opération de journalisation, cette opération n'est terminée que dans le thread maître et l'opération fsync de redo log est effectuée toutes les 1 seconde dans le thread maître, donc l'instance plante. perdra les transactions en 1 seconde au maximum. (Le thread maître est chargé d'actualiser de manière asynchrone les données du pool de mémoire tampon sur le disque pour garantir la cohérence des données) Les opérations

fsync et write sont en fait des fonctions d'appel système. est utilisé dans de nombreux scénarios de persistance. Par exemple, deux fonctions sont également utilisées dans la persistance AOF de Redis. L'opération fsync soumet les données au disque dur, forçant la synchronisation du disque dur, et se bloquera jusqu'à ce que l'écriture sur le disque dur soit terminée et revienne. L'exécution d'un grand nombre d'opérations fsync entraînera un goulot d'étranglement des performances, tandis que l'opération write soumet les données au disque dur, forçant la synchronisation du disque dur, et se bloquera jusqu'à ce que l'écriture sur le disque dur soit terminée et revienne.

L'opération écrit les données dans le cache de pages du système. Revenez immédiatement, puis comptez sur le mécanisme de planification du système pour vider les données mises en cache sur le disque. L'ordre est tampon utilisateur——>cache de pages——>disque.

En plus du mécanisme Force Log at Commit mentionné ci-dessus pour assurer la durabilité des transactions, la mise en œuvre du redo log dépend en fait aussi activé pour une mini-transaction.

Comment Redo est-il implémenté dans InnoDB ? Connexion à une mini-transaction ?

L'implémentation de Redo est en fait étroitement liée à la mini-transaction. La mini-transaction est un mécanisme utilisé en interne par InnoDB pour garantir les données de la page de données lors des opérations de transaction simultanées. et quand la base de données est anormale

, mais elle ne fait pas partie de la transaction.

Pour que la mini-transaction assure la cohérence des données de la page de données, la mini-transaction doit suivre les trois protocoles suivants

 :

• Le Règles FIX

• Journal d'écriture anticipée

• Forcer le journal à la validation

Les règles FIX

Lors de la modification d'une page de données, vous devez obtenir le x-latch (verrouillage exclusif) de la page. Lors de l'acquisition d'une page de données, vous avez besoin du s-latch (lire. lock ou verrou partagé) de la page ) ou x-latch, qui maintient le verrou sur la page jusqu'à ce que l'opération de modification ou d'accès à la page soit terminée.

Journal d'écriture anticipée

Le journal d'écriture anticipée a été mentionné dans l'explication précédente. Avant de conserver une page de données, la page de journal correspondante en mémoire doit d'abord être conservée. Chaque page possède un LSN (numéro de séquence de journal), qui représente le numéro de séquence du journal (LSN occupe 8 octets et augmente de manière monotone). Lorsqu'une page de données doit être écrite sur un périphérique persistant, elle nécessite moins que le LSN de la page. dans la mémoire. Le journal est d'abord écrit sur le périphérique de persistance

Alors pourquoi devons-nous d'abord écrire le journal ? Est-il possible d’écrire des données directement sur le disque sans écrire de journaux ? En principe, c'est possible, mais cela entraînera certains problèmes. La modification des données générera des E/S aléatoires, mais le journal est une E/S séquentielle. La méthode d'ajout écrit de manière séquentielle, ce qui est une méthode série, afin que les performances du disque puissent être pleinement optimisées. utilisé.

Force-log-at-commit

Voici le contenu de la façon d'assurer la durabilité des transactions mentionnées ci-dessus. Voici à nouveau un résumé, et ce qui précède. le contenu correspond. Plusieurs pages peuvent être modifiées dans une transaction. Le journal Write-Ahead peut garantir la cohérence d'une seule page de données, mais ne peut pas garantir la durabilité de la transaction. Le journal forcé à la validation nécessite que lorsqu'une transaction est validée, elle génère toutes. mini -Le journal des transactions doit être vidé sur le disque. Si, une fois le vidage du journal terminé, la base de données se bloque avant que les pages du pool de mémoire tampon ne soient vidées sur le périphérique de stockage persistant, l'intégrité des données peut être compromise au redémarrage de la base de données. être assuré par le biais du journal.

Processus d'écriture du journal redo

La figure ci-dessus montre l'écriture du processus de journalisation, chaque mini -transaction correspond à chaque opération DML, telle qu'une instruction de mise à jour, qui est garantie par une mini-transaction. Une fois les données modifiées, redo1 est généré, qui est d'abord écrit dans le Buffer privé de la mini-transaction, et la mise à jour. instruction Une fois terminé, copiez redo1 du tampon privé vers le tampon de journal public. Lorsque la totalité de la transaction externe est validée, le tampon de journalisation est vidé dans le fichier de journalisation.

undo log

Définition du journal d'annulation

undo log enregistre principalement les modifications logiques des données, afin de rouler revenir à l'opération précédente lorsqu'une erreur se produit, vous devez enregistrer toutes les opérations précédentes, puis revenir en arrière lorsqu'une erreur se produit.

Le rôle du journal d'annulation

l'annulation est un journal logique qui a deux fonctions :

• Pour les transactions Rollback

• MVCC

Je ne dirai pas grand-chose sur MVCC (Multi-version Concurrency Control) ici. Cet article se concentre sur l'annulation du journal pour l'annulation des transactions.

undo log restaure logiquement uniquement la base de données à son état d'origine. Lors du rollback, il fait en fait le travail inverse. Par exemple, un INSERT correspond à un DELETE, et pour chaque UPDATE, cela correspond à une mise à jour inversée. reculer la ligne avant modification. Le journal d'annulation est utilisé pour les opérations d'annulation de transaction afin de garantir l'atomicité de la transaction.

Moment d'écriture du journal d'annulation

• Avant que l'opération DML ne modifie l'index clusterisé, enregistrez le journal d'annulation

• Les modifications apportées aux enregistrements d'index secondaire n'enregistrent pas les journaux d'annulation

Il convient de noter que les modifications apportées aux pages d'annulation doivent également enregistrer des journaux de rétablissement.

L'emplacement de stockage de l'annulation

Dans le moteur de stockage InnoDB, l'annulation est stockée dans le segment de restauration (Rollback Segment), chaque segment d'annulation enregistre 1 024 segments de journal d'annulation et l'annulation est effectuée dans chaque segment de journal d'annulation. Pour demander une page, avant la version 5.6, le segment de restauration se trouvait dans l'espace table partagé. Après la version 5.6.3, vous pouvez utiliser. innodb_undo_tablespace définit l'emplacement de stockage des annulations.

Type d'annulation

Dans le moteur de stockage InnoDB, le journal d'annulation est divisé en :

• insérer le journal d'annulation

• mettre à jour le journal d'annulation

insérer le journal d'annulation fait référence au journal d'annulation généré lors de l'opération d'insertion, car l'enregistrement de l'opération d'insertion n'est visible que par la transaction elle-même. Invisible pour les autres transactions. Par conséquent, le journal d'annulation peut être supprimé directement après la validation de la transaction et aucune opération de purge n'est requise.

Le journal d'annulation de mise à jour enregistre le journal d'annulation généré par les opérations de suppression et de mise à jour. Le journal d'annulation peut devoir fournir un mécanisme MVCC, il ne peut donc pas être supprimé lorsque la transaction est validée. Lors de la soumission, placez-le dans la liste du journal d'annulation et attendez que le thread de purge effectue la suppression finale.

Supplément : Les deux fonctions principales du thread de purge sont : nettoyer la page d'annulation et effacer les lignes de données avec l'indicateur Delete_Bit dans la page. Dans InnoDB, l'opération Supprimer dans une transaction ne supprime pas réellement la ligne de données, mais une opération Supprimer Marquer qui marque le Delete_Bit sur l'enregistrement sans supprimer l'enregistrement. Il s'agit d'une sorte de "fausse suppression", qui est simplement marquée. Le vrai travail de suppression doit être effectué par le thread de purge en arrière-plan.

L'annulation du journal est-elle le processus inverse du rétablissement du journal ?

Le journal d'annulation est-il rétabli ? Le processus inverse de journalisation ? En fait, la réponse peut être dérivée de l'article précédent. Le journal d'annulation est un journal logique. Lors de l'annulation d'une transaction, il restaure logiquement la base de données à son état d'origine, tandis que le journal est rétabli. Le journal est un journal physique, qui enregistre les modifications physiques des pages de données. Évidemment, l'annulation du journal n'est pas le processus inverse du rétablissement du journal.

Résumé de rétablissement et d'annulation

Ce qui suit est un processus simplifié de rétablissement et d'annulation du journal pour faciliter la compréhension des deux processus de journalisation :

假设有A、B两个数据，值分别为1,2.
1. 事务开始
2. 记录A=1到undo log
3. 修改A=3
4. 记录A=3到 redo log
5. 记录B=2到 undo log
6. 修改B=4
7. 记录B=4到redo log
8. 将redo log写入磁盘
9. 事务提交

En fait, dans les opérations d'insertion/mise à jour/suppression, refaire et annuler enregistrer différents contenus et montants. Dans la mémoire InnoDB, l'ordre général est le suivant :

• Écrire annuler refaire

• Écrire annuler

• Modifier la page de données

• Écrire Refaire

Résumé

Cet article analyse la transaction Les journaux de rétablissement et d'annulation sont compilés en référence à certains manuels d'information. Certains endroits peuvent ne pas être clairement indiqués. S'il y a quelque chose qui ne va pas, veuillez le signaler.

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!