Disposition spéciale des journaux MySQL : refaire le journal et annuler le journal

Cet article vous apporte des connaissances pertinentes sur mysql. Le journal MySQL enregistre les opérations quotidiennes et les informations sur les erreurs de la base de données MySQL. MySQL a différents types de fichiers journaux (chacun stocke différents types de journaux, vous pouvez interroger). l'état d'exécution, les opérations utilisateur, les messages d'erreur, etc. de la base de données MySQL. Jetons-y un coup d'œil, j'espère que cela sera utile à tout le monde.

Apprentissage recommandé : Tutoriel vidéo mysql

Redo Log

REDO LOG est appelé un redo log Lorsque le serveur MySQL plante ou tombe en panne de manière inattendue, il garantit que les transactions soumises sont conservées sur le disque (persistance). .

InnoDB exploite les enregistrements en unités de pages. Les ajouts, suppressions, modifications et requêtes chargeront la page entière dans le pool de tampons (disque -> mémoire). L'opération de modification dans la transaction ne modifie pas directement les données sur le disque, mais). modifiez-le d'abord. Les données du pool de mémoire tampon sont actualisées de manière asynchrone sur le disque par le thread d'arrière-plan à intervalles réguliers.

Pool de tampons : il peut stocker des index et des données, accélérer la lecture et l'écriture, exploiter directement les pages de données en mémoire et dispose d'un thread dédié pour écrire les pages sales du pool de tampons sur le disque.

Pourquoi ne pas modifier directement les données sur le disque ?

Parce que si vous modifiez directement les données du disque, il s'agit d'E/S aléatoires. Les données modifiées sont distribuées à différents emplacements sur le disque et doivent être recherchées dans les deux sens. Par conséquent, le taux de réussite est faible et la consommation est élevée. , une petite modification devra remplacer la page entière. Le vidage sur le disque a une faible utilisation

Contrairement aux E/S séquentielles, les données du disque sont distribuées dans une seule partie du disque, donc le processus de recherche et le temps de recherche sont omis ; est sauvegardé.

L'utilisation de threads d'arrière-plan pour actualiser le disque à une certaine fréquence peut réduire la fréquence des E/S aléatoires et augmenter le débit. C'est la raison fondamentale de l'utilisation du pool de mémoire tampon.

Le problème de la modification de la mémoire puis de sa synchronisation asynchrone sur le disque :

Étant donné que le pool de tampons est une zone de la mémoire, si le système plante de manière inattendue, les données peuvent être perdues. Certaines données sales peuvent ne pas être actualisées. le disque à temps, et la durabilité de la transaction ne sera pas garantie. Par conséquent, le journal redo a été introduit. Lors de la modification des données, un journal supplémentaire est enregistré, qui montre que le décalage xx de la page xx a changé de xx. Lorsque le système tombe en panne, il peut être récupéré en fonction du contenu du journal.

La différence entre l'écriture de journaux et l'actualisation directe du disque est la suivante : l'écriture de journaux consiste à ajouter une écriture, des E/S séquentielles, plus rapide et le contenu écrit est relativement plus petit

redo log se compose de deux parties :

1. redo log buffer (niveau de mémoire , par défaut 16 Mo, peut être modifié via le paramètre innodb_log_buffer_size)
2. fichier journal redo (persistant, niveau disque)

Le processus général de l'opération de modification :

Étape 1 : Lisez d'abord les données originales du disque dans la mémoire, modifiez la copie mémoire des données et générez des données sales

É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 : Par défaut, dans la transaction Après la soumission, 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 les données modifiées dans la mémoire sur le disque (nous parlons ici à propos des données qui n'ont pas été mises à jour à temps (données sales vidées par les threads d'arrière-plan)

Le communément appelé journal d'écriture anticipée (persistance avant le journal) fait référence à la persistance de la page de journal correspondante dans la mémoire avant de conserver une page de données.

Avantages du redo log :

• Réduit la fréquence de rafraîchissement du disque
• redo log prend peu de place
• redo log écrit rapidement

Le redo log peut-il définitivement garantir la durabilité des transactions ?

Pas nécessairement, cela dépend de la stratégie de vidage du journal redo, car le tampon redo log est également en mémoire si après la soumission de la transaction, le tampon redo log n'a pas eu le temps d'actualiser les données dans le fichier redo log pour des raisons de persistance. . À ce stade, les données seront toujours perdues en cas d'indisponibilité. Comment le résoudre ? Stratégie de balayage.

Stratégie de vidage du journal redo

InnoDB propose trois stratégies pour le paramètre innodb_flush_log_at_trx_commit pour contrôler le moment où le tampon de journalisation est vidé dans le fichier de journalisation :

• La valeur est 0 : démarrez un thread d'arrière-plan et videz-le sur le disque tous les 1s , il n'est pas nécessaire de rafraîchir lors de la validation d'une transaction
• La valeur est 1 : un rafraîchissement synchrone est effectué lors de la validation (valeur par défaut), ce qui garantit véritablement la pérennité des données
• La valeur est 2 : Lors de la validation, c'est uniquement rafraîchi dans la zone tampon du noyau du système d'exploitation, le moment spécifique du vidage du disque est incertain

Le cas où la valeur est 0 :

Parce qu'il y a un intervalle de 1 s, 1 seconde de données sera perdue dans le le pire des cas. Le cas où

value est 1 :

Lors de la validation, vous devez actualiser activement le tampon de journalisation dans le fichier de journalisation. Si la machine tombe en panne à mi-chemin, la transaction échouera sans aucune perte. Cela peut véritablement garantir la durabilité de la transaction. Mais l'efficacité est la pire.

Si la valeur est 2 : elle est déterminée en fonction du système d'exploitation.

Peut être ajusté à 0 ou 2 pour améliorer les performances de la transaction, mais les caractéristiques ACID sont perdues

Autres paramètres

• innodb_log_group_home_dir : Spécifiez le chemin où se trouve le groupe de fichiers de journalisation. La valeur par défaut est ./, ce qui signifie qu'il est utilisé. se trouve dans le répertoire data de la base de données. Il existe deux fichiers nommés ib_logfile0 et ib_logfile1 dans le répertoire de données par défaut de MySQL. Les journaux du tampon de journal sont vidés par défaut dans ces deux fichiers disque.
• innodb_log_files_in_group : Spécifie le nombre de fichiers de journalisation. La méthode de dénomination est telle que : ib_logfile0, iblogfile1... iblogfilen. La valeur par défaut est 2, le maximum est 100.
• innodb_log_file_size : définissez la taille d'un seul fichier de journalisation, la valeur par défaut est de 48 Mo.

Undo Log

undo log est utilisé pour garantir l'atomicité et la cohérence des transactions. Il a deux fonctions : ① Fournir une opération de restauration ② Contrôle multi-version MVVC

Opération de restauration

Comme mentionné dans le journal redo plus tôt, le thread d'arrière-plan actualisera les données du pool de mémoire tampon sur le disque de temps en temps, mais si le la transaction est exécutée Pendant cette période, diverses erreurs (temps d'arrêt) se produisent ou des instructions d'annulation sont exécutées, puis les opérations précédemment brossées doivent être annulées pour garantir l'atomicité. Le journal d'annulation fournit l'annulation de la transaction.

MVVC

Lorsqu'une ligne de lecture est verrouillée par une autre transaction, elle peut analyser la version précédente des données enregistrée dans la ligne à partir du journal d'annulation, permettant aux utilisateurs de lire les données avant l'opération de transaction en cours — — Lecture instantanée.

Lecture d'instantané : les données lues par SQL sont la version historique, aucun verrouillage n'est requis, SELECT ordinaire est une lecture d'instantané.

Composants du journal d'annulation :

• Lors de l'insertion d'un enregistrement, la valeur de clé primaire de l'enregistrement doit être enregistrée afin que les données puissent être supprimées lors de la restauration.
• Lors de la mise à jour des enregistrements, toutes les anciennes valeurs modifiées doivent être enregistrées, puis mises à jour avec les anciennes valeurs lors de la restauration.
• Lors de la suppression, tous les enregistrements doivent être enregistrés et les enregistrements du contenu doivent être réinsérés lors de la restauration.

L'opération de sélection ne générera pas de journal d'annulation

Segment d'annulation et page d'annulation

Dans le moteur de stockage InnoDB, le journal d'annulation utilise le segment d'annulation du segment d'annulation pour le stockage, et chaque segment d'annulation contient 1024 segments de journal d'annulation. Après MySQL5.5, il y a un total de 128 segments de restauration. Autrement dit, un total de 128 * 1024 opérations d'annulation peuvent être enregistrées.

Chaque transaction n'utilisera qu'un seul segment d'annulation, et un segment d'annulation peut servir plusieurs transactions en même temps.

Le journal d'annulation ne peut pas être supprimé immédiatement après la soumission de la transaction. Certaines transactions peuvent vouloir lire la version précédente des données (lecture instantanée). Par conséquent, lorsqu'une transaction est validée, le journal d'annulation est placé dans une liste chaînée, appelée chaîne de versions. Le fait que le journal d'annulation soit supprimé ou non est jugé par un thread appelé purge.

Type d'annulation

Le journal d'annulation est divisé en :

insérer le journal d'annulation

Parce que l'enregistrement de l'opération d'insertion n'est visible que par la transaction elle-même et non par les autres transactions (il s'agit d'une exigence d'isolation des transactions), donc l'annulation log peut être supprimé directement après la validation de la transaction. Aucune opération de purge n’est requise.

mettre à jour le journal d'annulation

mettre à jour le journal d'annulation enregistre le journal d'annulation généré par les opérations de suppression et de mise à jour. Le journal d'annulation devra peut-être fournir un mécanisme MVCC afin qu'il ne puisse 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.

Le cycle de vie du journal d'annulation

Supposons qu'il y ait 2 valeurs, A=1 et B=2, puis qu'une transaction modifie A en 3 et B en 4. Le processus de modification peut être simplifié comme suit :

1 . start
2.Enregistrez A=1 pour annuler le journal
3.update A=3
4.Enregistrez A=3 pour refaire le journal
5.Enregistrez B=2 pour annuler le journal
6.update B=4
7.Enregistrez B =4 pour refaire le journal
8. Actualiser le journal de rétablissement sur le disque
9.commit

• Si le système tombe en panne à l'une des étapes 1 à 8 et que la transaction n'est pas soumise, la transaction ne fera rien aux données. sur le disque.
• S'il descend entre 8 et 9, vous pouvez choisir de revenir en arrière après la récupération, ou vous pouvez choisir de continuer à terminer la soumission de la transaction, car le journal redo a été conservé à ce moment-là.
• Si le système tombe en panne après 9 heures et que les données modifiées dans la carte mémoire n'ont pas eu le temps d'être réinjectées sur le disque, une fois le système récupéré, les données peuvent être réintroduites sur le disque conformément au journal de rétablissement.

Processus de génération détaillé

Pour le moteur InnoDB, en plus des données de l'enregistrement lui-même, chaque enregistrement de ligne comporte également plusieurs colonnes cachées :

• DB_ROW_ID∶L'identifiant de clé primaire de l'enregistrement.
• DB_TRX_ID : ID de transaction Lorsqu'un enregistrement est modifié, l'ID de la transaction sera enregistré.
• DB_ROLL_PTR : Pointeur de rollback, pointeur dans la chaîne de versions.

Lorsque nous exécutons INSERT :

begin;
INSERT INTO user (name) VALUES ('tom');

Les données insérées généreront un journal d'annulation d'insertion et le pointeur de restauration des données y pointera. Le journal d'annulation enregistrera le numéro de série du journal d'annulation, la colonne et la valeur de la clé primaire insérée... Ensuite, lors de la restauration, les données correspondantes peuvent être supprimées directement via la clé primaire.

Lorsque nous exécutons UPDATE :

Le journal d'annulation de mise à jour sera généré pour l'opération de mise à jour, et il sera divisé en ceux qui mettent à jour la clé primaire et ceux qui ne mettent pas à jour la clé primaire. Supposons que nous exécutions maintenant :

UPDATE user SET name='Sun' WHERE id=1;

À ce moment, le nouveau journal sera généré. L'enregistrement du journal d'annulation est ajouté à la chaîne de versions, son numéro d'annulation est 1 et le pointeur d'annulation du nouveau journal d'annulation pointera vers l'ancien journal d'annulation ( annuler non = 0).

Supposons que vous exécutiez maintenant :

UPDATE user SET id=2 WHERE id=1;

Pour l'opération de mise à jour de la clé primaire, l'indicateur de suppression des données d'origine sera ouvert en premier. À ce stade, les données ne seront pas réellement supprimées. le thread de nettoyage pour juger, puis dans Si une nouvelle donnée est insérée plus tard, les nouvelles données généreront également un journal d'annulation et le numéro de séquence du journal d'annulation augmentera.

Vous pouvez constater que chaque modification apportée aux données générera un journal d'annulation. Lorsqu'un enregistrement est modifié plusieurs fois, plusieurs journaux d'annulation seront générés. Le journal d'annulation enregistre le journal avant la modification, et chaque journal d'annulation Le numéro de séquence augmente. , donc lorsque vous souhaitez revenir en arrière, avancez en fonction du numéro de séquence pour retrouver nos données d'origine.

Comment le journal d'annulation est annulé

En prenant l'exemple ci-dessus, en supposant que la restauration est exécutée, le processus correspondant devrait être le suivant :

1 Supprimez les données avec l'identifiant = 2 via le journal d'annulation no = 3

2. . Restaurez la marque de suppression des données avec id=1 à 0 via le journal d'annulation no=2 3. Restaurez le nom des données avec id=1 à Tom via le journal d'annulation no=1. des données avec id=1 à Tom via undo no=. Le journal de 0 supprime les données avec id=1

Contrôle de concurrence multi-version MySQL MVVC

extension

bin log

binlog est un journal binaire, un journal binaire fichier, également appelé journal des modifications (journal de mise à jour). Il enregistre toutes les instructions de mise à jour exécutées par la base de données.

Principaux scénarios d'application de binlog :

Récupération de données : si MySQL s'arrête de manière inattendue, le journal peut être utilisé pour la récupération et la sauvegarde

Réplication de données : le maître transfère son journal binaire aux esclaves pour assurer la cohérence des données maître-esclave

• show variables like '%log_bin%';

Afficher le journal du journal bin :

• mysqlbinlog -v "/var/lib/mysql/binlog/xxx.000002"

Utiliser le journal pour récupérer les données :

mysqlbinlog [option] filename|mysql –uuser -ppass;

Supprimer le journal binaire :

PURGE {MASTER | BINARY} LOGS TO ‘指定日志文件名'
PURGE {MASTER | BINARY} LOGS BEFORE ‘指定日期'

Minutage d'écriture

Pendant l'exécution de la transaction, le journal est d'abord écrit dans le cache du journal bin. La transaction est soumise, puis écrivez le cache binlog dans le fichier binlog. Étant donné que le journal binaire d'une transaction ne peut pas être divisé, quelle que soit la taille de la transaction, il doit être écrit une fois, de sorte que le système alloue un bloc de mémoire à chaque thread en tant que cache du journal binaire.

Comparaison entre binlog et redo log

redo log est un journal physique. Le contenu de l'enregistrement est "xx modifications ont été apportées sur xx page de données", qui est généré par la couche du moteur de stockage InnoDB.

Le binlog est un journal logique, et le contenu enregistré est la logique originale de l'instruction. Cela revient à ajouter 1 au champ c de la ligne avec ID=2, qui appartient à la couche de service.

• Les deux objectifs sont également différents. Redo log donne à InnoDB la possibilité de se remettre d'un crash, et binlog garantit la cohérence des données de l'architecture du cluster MySQL.
• Commit en deux étapes

Pendant l'exécution de l'instruction de mise à jour, deux journaux, redo log et binlog, seront enregistrés. Sur la base des transactions de base, le redo log peut être écrit en continu pendant l'exécution de la transaction, tandis que le binlog ne peut que le faire. être écrit lorsque la transaction est soumise en écriture, donc le moment de l'écriture du journal redo et du binlog est différent.

La logique entre le redo log et le binlog est incohérente. Quels problèmes vont survenir ?

Prenons l'exemple de l'instruction update. Supposons que pour l'enregistrement avec id=2, la valeur du champ c est 0. Mettez à jour la valeur du champ c à 1. L'instruction SQL est update T set c=1 où id=2.

Supposons qu'après l'écriture du journal redo pendant le processus d'exécution, une exception se produise lors de l'écriture du journal binlog.

Parce que le binlog est anormal avant la fin de son écriture, il n'y a pas de correspondance. enregistrement de modification dans le binlog à ce moment. Par conséquent, lorsque le journal binlog est utilisé pour restaurer des données ou que l'esclave lit le journal binlog du maître, cette mise à jour sera omise. La valeur c de la ligne restaurée est 0, alors que dans la base de données d'origine, en raison de la restauration du journal redo, la valeur c. la valeur de cette ligne est 1. Les données finales sont incohérentes.

Afin de résoudre le problème de cohérence logique entre les deux journaux, le moteur de stockage InnoDB utilise un schéma de validation en deux phases. Divisez le journal de rétablissement en deux étapes, préparez et validez, ce qui est une validation en deux étapes.

Laissez la soumission finale du journal redo et du journal bin être liée ensemble. Comme mentionné précédemment, lorsqu'une transaction est validée, par défaut, le journal redo doit être synchronisé avant que la validation soit réussie, donc s'ils sont liés ensemble, le journal redo doit être synchronisé. bin log a également cette fonctionnalité, elle garantit que les données ne seront pas perdues.

Après avoir utilisé la validation en deux phases, il n'y aura aucun impact si une exception se produit lors de l'écriture dans le binlog, car lorsque MySQL restaure les données basées sur le journal redo, il constate que le journal redo est toujours en phase de préparation et il n'y a pas de journal binlog correspondant, donc la soumission échoue, annulez les données.

Dans un autre scénario, une exception se produit lors de la phase de validation du journal redo. La transaction sera-t-elle annulée ?

n'annulera pas la transaction, il exécutera la logique encadrée dans l'image ci-dessus. Bien que le journal redo soit en phase de préparation, le journal binlog correspondant peut être trouvé via l'ID de transaction, donc MySQL le considère comme tel. être terminée. Validez la transaction pour restaurer les données.

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!