Quel est le concept des journaux de rétablissement MySQL

Dans les caractéristiques ACID des transactions, l'atomicité (A), la cohérence (C) et la durabilité (D) sont réalisées par undo log et redo log, et l'isolation (I) est réalisée par lock + MVCC

undo log : La transaction n'a pas encore été validée et l'exécution est anormale au milieu. Vous pouvez utiliser le journal d'annulation pour restaurer les données à l'état avant l'exécution de la transaction afin de garantir l'atomicité de la transaction #🎜🎜. #

redo log : La transaction est validée avec succès. Comme la mise à jour des données du disque prend un certain temps, si une exception se produit à ce moment-là, vous pouvez utiliser redo log pour réexécuter le SQL de cette transaction afin d'assurer la durabilité. de la transaction (

Tant que la validation de la transaction est réussie, quel que soit l'événement anormal qui se produit, tant que la prochaine fois Le service MySQL fonctionne normalement et les données de la dernière validation doivent être restaurées. Qu'est-ce que enregistrée est la page de données modifiées finale stockée par page, qui stocke directement l'état final des données et est utilisée pour assurer la durabilité de la transaction Le journal logique est également appelé journal d'annulation, qui enregistre les instructions SQL correspondantes. Si l'insertion est exécutée maintenant, la suppression sera exécutée lors de la restauration ; si la mise à jour est exécutée maintenant, l'ancienne valeur d'origine sera à nouveau mise à jour

Le journal de rétablissement est placé sous

par défaut#🎜 🎜#

redo log commence à enregistrer lorsque la transaction commence /var/lib/mysql (il n'est pas enregistré lorsque la transaction est validée, car la totalité de la transaction est effectuée Il peut y avoir de nombreuses opérations. Si le journal redo est écrit au moment de la validation, si une exception se produit à ce moment-là, le journal redo n'a pas encore été écrit, il est trop tard et la durabilité de la transaction ne peut pas être garantie.) Que la transaction soit validée ou non, elle sera enregistrée après l'exception, lorsqu'elle se produit (comme une panne de courant pendant la persistance des données), InnoDB utilisera le journal redo pour restaurer au moment précédant la panne de courant afin de garantir l'intégrité des données

innodb_log_buffer_size La valeur par défaut est 16M, qui est la taille du tampon de journalisation, il commence à écrire le journal de redo au démarrage de la transaction si la transaction est relativement volumineuse, afin d'éviter de trop dépenser. Si vous avez beaucoup d'E/S disque pendant l'exécution d'une transaction, vous pouvez configurer un cache de journalisation relativement important pour enregistrer les E/S disque. Il y a un temps d'actualisation lors du vidage sur le disque. Lorsque l'heure est atteinte, les E/S du disque sont consommées. Si le tampon est relativement volumineux, le temps d'actualisation sera atteint plus lentement et l'efficacité sera plus élevée.

InnoDB modifie les données d'opération, sans modifier directement les données sur le disque, mais en modifiant simplement les données dans le pool de tampons # 🎜🎜#. InnoDB enregistre toujours d'abord les modifications de données dans le pool de tampons dans le journal redo pour la récupération des données après un crash. Enregistrez d'abord le journal redo, puis trouvez une opportunité d'actualiser lentement les données sales du pool de tampons sur le disque.

innodb_log_group_home_dir Spécifié deux fichiers dans le répertoire : ib_logfile0, ib_logfile1, ce fichier est appelé le redo log

buffer pool buffer pool : #🎜🎜 # Peut stocker le cache d'index, le cache de données, etc., peuvent accélérer la lecture et l'écriture, faire fonctionner directement la page de données, écrire la modification du journal redo, et même si elle est terminée, il y aura un thread dédié pour écrire la page sale dans le pool de tampons sur le disque

#🎜🎜 #La taille par défaut du pool de tampons est de 134 Mo (MySQL 5.7)

La structure approximative est celle indiquée dans le chiffre :

Les lectures et modifications de transactions donnent toutes la priorité aux données dans le pool de cache. Dans les projets réels, mysqld fonctionnera sur une machine distincte, qui peut allouer une grande quantité de mémoire spécifiquement pour le pool de tampons d'InnoDB afin d'accélérer CRUD

2. Cache et structure du disque#🎜🎜 #

Lorsqu'une transaction est validée, l'opération sur le diagramme de relations consiste à écrire le contenu du tampon de journal InnoDB sur le disque. Si l'écriture réussit, le rétablissement de la connexion sur le disque. le disque enregistrera l'état&mdash ;—commit, si l'écriture échoue ou est terminée, l'état d'enregistrement——prepare

log peut également provoquer des anomalies, des pannes de courant et d'autres problèmes pendant le processus d'écriture sur le disque, ce qui entraîne que le journal redo n'a pas été terminé (cela équivaut à un échec de validation de la transaction). À ce stade, MySQL n'a pas besoin de prendre en compte l'intégrité de la transaction lors de sa prochaine récupération, car l'état). n'est pas validé et est écrit sur le disque pour indiquer une restauration. Le journal est écrit avec succès et l'état passe à commit. Une fois le statut modifié en validation, les caractéristiques ACID de la transaction doivent être conservées.

Les données sales dans le sondage du tampon (les données ont été modifiées) sont-elles écrites sur le disque uniquement lors de la validation ?

Il n'est pas nécessaire d'attendre que le commit démarre. La quantité de données que la transaction peut modifier est relativement importante et la capacité du cache est limitée. Pour les données mises en cache dans l'interrogation du tampon, il y aura un thread dédié pour actualiser le disque au moment approprié en cas de panne de courant. , au prochain démarrage de MySQL, il sera actualisé selon la restauration. Les données enregistrées dans le journal sont restaurées.

undo log lui-même est également enregistré dans redo log

Le journal d'annulation prend en charge l'annulation des transactions et ne peut pas être terminé en un instant. Les données sur le disque sont finalement modifiées. Afin d'éviter des exceptions pendant le processus d'annulation, le journal d'annulation doit être enregistré dans le journal de rétablissement. Pour la couche inférieure, une fois l'opération écrite avec succès dans le journal redo, que la transaction soit validée avec succès (commit) ou annulée avec succès (rollback), elle est considérée comme réussie.

Qu'est-ce qu'un véritable succès de validation de transaction ?

Au lieu de vider toutes les données sur le disque, le journal redo enregistrant l'opération complète de la transaction est écrit sur le disque à partir du tampon de journal, puis l'état des données modifiées est défini sur commit pour réussir la transaction. commettre. Bien que les données soient toujours dans le tampon d'interrogation à ce moment-là, tant que notre journal de rétablissement reste intact, les données peuvent être restaurées. Il y aura un thread dédié chargé d'écrire les données du tampon d'interrogation sur le disque

. Lorsqu'une transaction est en cours, il faut toujours écrire le redo log en premier, puis le pool de tampons ; si la transaction est validée avec succès, il est nécessaire de s'assurer que le redo log est complètement enregistré sur le disque. données de la table, nous n'avons pas du tout besoin d'actualiser les pages de données sales du pool de mémoire tampon sur le disque. Inquiétez-vous, tant que le journal redo est complètement écrit sur le disque, nous pouvons restaurer l'état des données de la transaction validée avec succès. le refaire le journal à tout moment (

La chose la plus importante dans une base de données est le journal, pas 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!