Quels sont les points de connaissance du rétablissement et de l'annulation du journal dans les journaux 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

le journal redo se compose de deux parties :

1. tampon de journal redo (mémoire niveau, par défaut 16M, 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 : Convertissez d'abord l'original données Lisez le 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 du journal redo, en enregistrant la valeur modifiée des données

Étape 3 : Par défaut, une fois la transaction soumise, le contenu du tampon de journalisation est vidé dans le fichier de journalisation et le fichier de journalisation est ajouté au fichier

Étape 4 : Actualisez régulièrement les données modifiées dans la mémoire pour. le disque (ce qui est dit ici, ce sont des données sales qui n'ont pas été vidées par le thread d'arrière-plan à temps)

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 persistance d'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 disque tous les 1s , il n'est pas nécessaire de rafraîchir lors de la soumission 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 : Lorsque validation, il est juste actualisé Entrez le tampon du noyau du système d'exploitation, le temps de vidage spécifique 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. perdu dans le pire des cas.

Situation où la valeur est 1 :

Lors de la validation, vous devez actualiser activement le tampon de journalisation dans le fichier de journalisation. S'il descend au milieu, la transaction échouera et il n'y aura pas de problème. perte. La transaction peut vraiment être garantie. 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 des transactions, mais perdre les caractéristiques ACID

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 se trouve dans le répertoire de données 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.

• Par défaut, la taille de innodb_log_file_size est définie sur 48 Mo, qui est utilisée pour le paramètre de taille d'un seul fichier de journalisation.

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 stocker, 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.

La suppression du journal d'annulation ne peut pas être effectuée immédiatement après la validation de la transaction, car 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.

journal d'annulation de mise à jour

Les journaux d'annulation enregistrent les modifications apportées aux opérations de suppression et de mise à jour. Afin de prendre en charge le mécanisme MVCC, le journal d'annulation ne peut pas être supprimé immédiatement lorsque la transaction est validée. Lors de la soumission, ajoutez-le à la liste du journal d'annulation et attendez que le fil de nettoyage 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 n'affectera pas les données sur le disque. Ne faites aucun impact.

• 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 de rétablissement 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 restauré, les données peuvent être réintroduites sur le disque selon les refaire le journal.

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');

Chaque fois que des données sont insérées, un journal d'annulation de l'opération d'insertion sera créé et le pointeur de restauration des données pointera vers ce journal. 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 :

Lors de l'exécution d'une opération de mise à jour, un journal d'annulation de mise à jour sera généré, comprenant deux cas de mise à jour de la clé primaire et de non-mise à jour de la clé primaire. Supposons que l'opération de mise à jour soit maintenant effectuée :

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

À ce moment, le nouvel enregistrement du journal d'annulation sera 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 (undo no=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

Journal binaire, également connu sous le nom de mise à jour. log, est un type de fichier journal au format binaire qui enregistre les modifications apportées à une base de données. 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, vous pouvez utiliser ce journal pour la récupération et la sauvegarde

• Réplication de données : le maître transmet son journal binaire aux esclaves pour obtenir des données maître-esclave Cohérence

• 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 journal bin cache et la transaction Lors de la soumission, é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

Le redo log généré par la couche du moteur de stockage InnoDB est un journal physique utilisé pour enregistrer "quelles modifications ont été apportées à quelles pages de données".

• 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 des crashs, et binlog assure 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 l'exécution, une exception se produise lors de l'écriture du journal binlog.

Étant donné que l'exception binlog interrompt l'écriture, il n'y a pas d'enregistrement de modification correspondant. 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 ultérieurement, cette mise à jour sera omise. La valeur c de la ligne restaurée est 0 et la valeur c de cette ligne dans la base de données d'origine est 1 en raison. à la récupération du journal redo. Les données finales sont incohérentes.

Le moteur de stockage InnoDB adopte un schéma de validation en deux étapes pour résoudre le problème de cohérence logique entre les deux journaux. La soumission en deux phases consiste à diviser le journal de rétablissement en deux étapes : préparer et valider.

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.

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!