Analysons ensemble le journal des transactions MySQL

Cet article vous apporte des connaissances pertinentes sur mysql, qui présente principalement les problèmes liés aux transactions MySQL. Les transactions sont une fonctionnalité importante qui distingue MySQL de NoSQL et constituent une technologie clé pour garantir la cohérence des données dans les bases de données relationnelles.

Apprentissage recommandé : Tutoriel vidéo d'apprentissage mysql

1. Transactions MySQL

Les transactions sont une fonctionnalité importante qui distingue MySQL de NoSQL et constituent une technologie clé pour assurer la cohérence des données dans les bases de données relationnelles. Une transaction peut être considérée comme l'unité d'exécution de base des opérations de base de données, qui peut inclure une ou plusieurs instructions SQL. Lorsque ces instructions sont exécutées, soit elles sont toutes exécutées, soit aucune n'est exécutée.

L'exécution d'une transaction comprend principalement deux opérations, le commit et le rollback.

Soumettre : valider, écrire les résultats de l'exécution de la transaction dans la base de données.

Rollback : restauration, restauration de toutes les instructions exécutées et renvoi des données avant modification.

Les transactions MySQL incluent quatre caractéristiques, connues sous le nom de quatre rois ACID.

Atomicité : les instructions sont soit entièrement exécutées, soit pas exécutées du tout. C'est la caractéristique principale d'une transaction. La transaction elle-même est définie par l'atomicité ; la mise en œuvre est principalement basée sur le journal d'annulation.

Durabilité : garantit que les données ne seront pas perdues en raison d'un temps d'arrêt ou d'autres raisons après la soumission de la transaction ; la mise en œuvre est principalement basée sur les journaux redo ;

Isolement : garantit que l'exécution de la transaction n'est pas autant que possible affectée par d'autres transactions ; par défaut Le niveau d'isolement est RR. La mise en œuvre de RR est principalement basée sur le mécanisme de verrouillage, les colonnes de données cachées, le journal d'annulation et le mécanisme de verrouillage de la clé suivante

Cohérence (Cohérence) : Le but ultime poursuivi par la transaction, la réalisation. La cohérence nécessite à la fois la base de données et la base de données. Les garanties au niveau de l'application nécessitent également des garanties au niveau de l'application.

Atomicité

L'atomicité d'une transaction est comme une opération atomique, ce qui signifie que la transaction ne peut pas être plus poussée. divisé. Soit toutes les opérations qu'il contient sont effectuées, soit aucune d'entre elles n'est effectuée ; si la transaction Si une instruction SQL ne s'exécute pas, l'instruction exécutée doit également être annulée et la base de données revient à l'état avant la transaction. 0 et 1, et il n'y a pas d'autres valeurs. L'atomicité de la transaction indique que la transaction est un tout. Lorsque la transaction ne réussit pas, toutes les instructions exécutées dans la transaction doivent être annulées, afin que la base de données renvoie. à l'état où la transaction n'a pas été démarrée.

L'atomicité de la transaction est obtenue via le journal d'annulation lorsque la transaction doit être annulée, le moteur InnoDB appellera le journal d'annulation pour annuler l'instruction SQL et implémenter la restauration des données.

Persistance

La durabilité de la transaction signifie qu'une fois la transaction soumise, les modifications de la base de données ne doivent pas être temporaires. Cela signifie qu'une fois la transaction validée, toute autre opération ou même une panne du système. n'affecte pas les résultats d'exécution de la transaction d'origine.

La persistance de la transaction se fait via le moteur de stockage InnoDB. Voir ci-dessous pour des idées d'implémentation spécifiques.

L'atomicité et la durabilité sont des propriétés d'un. transaction unique elle-même, tandis que l'isolement fait référence aux exigences d'isolement qui doivent être maintenues entre les transactions. Les effets des différentes transactions n'interfèrent pas les uns avec les autres, et les opérations d'une transaction sont isolées des autres transactions

Puisqu'une transaction peut non seulement. contiennent une instruction SQL, il est très probable que d'autres transactions démarrent pendant l'exécution de la transaction. Par conséquent, la concurrence de plusieurs transactions nécessite que les opérations entre les transactions soient isolées les unes des autres. synchronisation entre multi-threads. L'isolation entre les transactions est obtenue grâce au mécanisme de verrouillage

. Lorsqu'une transaction doit modifier une certaine ligne de données dans la base de données, elle doit d'abord verrouiller les données. ; les autres transactions n'exécuteront pas d'opérations sur les données verrouillées et ne peuvent qu'attendre que la transaction en cours soit validée ou annulée.

Le mécanisme de verrouillage n'est pas un concept inconnu Dans de nombreux scénarios, différentes implémentations de verrous sont possibles. utilisé pour protéger et synchroniser les données. Dans MySQL, les verrous peuvent également être divisés en différentes catégories selon différentes normes de division

Divisés selon la granularité : verrouillage de ligne, verrouillage de table, verrouillage de page

Divisé selon l'utilisation : serrure partagée, serrure exclusive

Répartis selon l'idée : serrure pessimiste, serrure optimiste

Connaissance du mécanisme de serrure Il y a beaucoup de points, mais faute de place, je vais les aborder tous. Voici une brève introduction aux verrous répartis selon la granularité.

Granularité : fait référence au niveau de raffinement ou d'exhaustivité des données stockées dans l'unité de données de l'entrepôt de données. Plus le degré de raffinement est élevé, plus le niveau de granularité est faible ; à l’inverse, plus le degré de raffinement est faible, plus le niveau de granularité est grand.

MySQL peut être divisé en verrous de ligne, verrous de table et verrous de page en fonction de la granularité des verrous.

Verrouillage de ligne : Le verrouillage avec la plus petite granularité, ce qui signifie que seule la ligne de l'opération en cours est verrouillée.

Verrouillage de table : Le verrouillage avec la granularité la plus grande, ce qui signifie que l'opération en cours verrouille toute la table ; ;

Verrouillage de page : Un verrou avec une granularité entre les verrous au niveau de la ligne et les verrous au niveau de la table, ce qui signifie verrouiller la page.

Division granulaire de la base de données

Ces trois types de verrous verrouillent les données à différents niveaux. En raison de différentes granularités, ils apportent différents avantages et inconvénients.

Le verrouillage de table verrouillera la table entière lors de l'exploitation des données, les performances de concurrence sont donc médiocres ;

Le verrouillage de ligne ne verrouille que les données qui doivent être exploitées et les performances de concurrence sont bonnes. Cependant, étant donné que le verrouillage lui-même consomme des ressources (l'obtention de verrous, la vérification des verrous, la libération des verrous, etc. consomment tous des ressources), l'utilisation de verrous de table peut économiser beaucoup de ressources lorsqu'il y a beaucoup de données verrouillées.

Différents moteurs de stockage dans MySQL prennent en charge différents verrous. MyIsam ne prend en charge que les verrous de table, tandis qu'InnoDB prend en charge à la fois les verrous de table et les verrous de ligne. Pour des raisons de performances, les verrous de ligne sont utilisés dans la plupart des cas.

Problèmes de lecture et d'écriture simultanées

Dans une situation simultanée, la lecture et l'écriture simultanées de MySQL peuvent provoquer trois types de problèmes : les lectures sales, la non-répétabilité et les lectures fantômes.

(1) Lecture sale : la transaction en cours lit les données non validées d'autres transactions, qui sont des données sales.

En prenant l'image ci-dessus comme exemple, lorsque la transaction A lit le volume de lecture de l'article, elle lit les données soumises par la transaction B. Si la transaction B n'est finalement pas soumise avec succès, entraînant l'annulation de la transaction, alors le montant lu n'est pas réellement modifié avec succès, mais la transaction A lit la valeur modifiée, ce qui est évidemment déraisonnable.

(2) Lecture non répétable : Les mêmes données sont lues deux fois dans la transaction A, mais les résultats des deux lectures sont différents. La différence entre une lecture sale et une lecture non répétable réside dans le fait que la première lit les données non validées par d'autres transactions, tandis que la seconde lit les données soumises par d'autres transactions.

En prenant l'image ci-dessus comme exemple, lorsque la transaction A lit les données du volume de lecture de l'article l'une après l'autre, les résultats sont différents. Cela signifie que lors de l'exécution de la transaction A, la valeur du volume lu a été modifiée par d'autres transactions. Cela rend les résultats de la requête de données non fiables et irréalistes.

(3) Lecture fantôme : Dans la transaction A, la base de données est interrogée deux fois selon une certaine condition. Le nombre de lignes dans les deux résultats de la requête est différent. Ce phénomène est appelé lecture fantôme. La différence entre la lecture non répétable et la lecture fantôme peut être facilement comprise comme suit : la première signifie que les données ont changé, et la seconde signifie que le nombre de lignes de données a changé.

En prenant l'image ci-dessus comme exemple, lors de l'interrogation d'articles avec 0

Niveaux d'isolement

Sur la base des trois problèmes ci-dessus, quatre niveaux d'isolement sont générés, indiquant différents degrés de propriétés d'isolement de la base de données.

Dans la conception réelle d'une base de données, plus le niveau d'isolement est élevé, plus l'efficacité de la concurrence de la base de données sera faible ; et si le niveau d'isolement est trop faible, la base de données rencontrera divers problèmes compliqués pendant le processus de lecture et d'écriture.

Ainsi, dans la plupart des systèmes de bases de données, le niveau d'isolement par défaut est en lecture validée (comme Oracle) ou en lecture répétable RR (moteur InnoDB de MySQL).

MVCC

Un autre gros morceau difficile à mâcher. MVCC est utilisé pour implémenter le troisième niveau d'isolement ci-dessus, qui peut lire RR à plusieurs reprises.

MVCC : Multi-Version Concurrency Control, un protocole de contrôle de concurrence multi-version.

La caractéristique de MVCC est qu'en même temps, différentes transactions peuvent lire différentes versions de données, résolvant ainsi les problèmes de lectures sales et de lectures non répétables.

MVCC réalise en fait la coexistence de plusieurs versions de données grâce à des colonnes de données cachées et des journaux de restauration (journal d'annulation). L'avantage est que lors de l'utilisation de MVCC pour lire des données, il n'est pas nécessaire de verrouiller, évitant ainsi les conflits de lecture et d'écriture simultanées.

Lors de la mise en œuvre de MVCC, plusieurs colonnes masquées supplémentaires seront enregistrées dans chaque ligne de données, telles que le numéro de version et l'heure de suppression lors de la création de la ligne actuelle et le pointeur de restauration vers le journal d'annulation. Le numéro de version ici n'est pas la valeur temporelle réelle, mais le numéro de version du système. Chaque fois qu'une nouvelle transaction est démarrée, le numéro de version du système est automatiquement incrémenté. Le numéro de version du système au début de la transaction sera utilisé comme numéro de version de la transaction, qui est utilisé pour comparer avec le numéro de version de chaque ligne d'enregistrements de la requête.

Chaque transaction a son propre numéro de version. De cette manière, lorsque des opérations sur les données sont effectuées au sein de la transaction, l'objectif du contrôle de version des données est atteint grâce à la comparaison des numéros de version.

De plus, le niveau d'isolement RR implémenté par InnoDB peut éviter le phénomène de lectures fantômes, qui est obtenu grâce au mécanisme de verrouillage de la clé suivante.

Le verrouillage de la touche suivante est en fait un type de verrouillage de ligne, mais il verrouille non seulement l'enregistrement de ligne actuel lui-même, mais verrouille également une plage. Par exemple, dans l'exemple ci-dessus de lecture fantôme, lorsque vous commencez à interroger des articles avec 0

Verrouillage des espaces : bloquer les espaces dans les enregistrements d'index

Bien qu'InnoDB utilise le verrouillage de la touche suivante pour éviter les problèmes de lecture fantôme, il ne s'agit pas d'une isolation véritablement sérialisable. Regardons un autre exemple.

Tout d'abord, permettez-moi de poser une question :

Au temps T6, après que la transaction A ait validé la transaction, devinez quel est le volume de lecture de l'article A et de l'article B ?

La réponse est que le volume de lecture de l'article AB a été modifié à 10 000. Cela signifie que la soumission de la transaction B affecte en réalité l'exécution de la transaction A, ce qui indique que les deux transactions ne sont pas complètement isolées. Bien qu'il puisse éviter le phénomène de lecture fantôme, il n'atteint pas le niveau de sérialisabilité.

Cela montre également qu'éviter les lectures sales, les lectures non répétables et les lectures fantômes est une condition nécessaire mais pas suffisante pour atteindre un niveau d'isolement sérialisable. La sérialisabilité peut éviter les lectures sales, les lectures non répétables et les lectures fantômes, mais éviter les lectures sales, les lectures non répétables et les lectures fantômes ne permet pas nécessairement d'obtenir la sérialisabilité.

Cohérence

La cohérence signifie qu'une fois la transaction exécutée, les contraintes d'intégrité de la base de données ne sont pas détruites et l'état des données est légal avant et après l'exécution de la transaction.

La cohérence est le but ultime poursuivi par les transactions. L'atomicité, la durabilité et l'isolement existent réellement pour garantir la cohérence de l'état de la base de données.

Plus rien à dire. Vous dégustez avec soin.

2. Système de journalisation MySQL

Après avoir compris l'architecture de base de MySQL, vous pouvez généralement avoir une compréhension plus claire du processus d'exécution de MySQL. Ensuite, je vais vous présenter le système de journalisation.

Le système de journalisation MySQL est un composant important de la base de données et est utilisé pour enregistrer les mises à jour et les modifications de la base de données. Si la base de données échoue, les données originales de la base de données peuvent être restaurées via différents enregistrements de journal. Par conséquent, en fait, le système de journalisation détermine directement la robustesse et la robustesse du fonctionnement de MySQL.

MySQL possède de nombreux types de journaux, tels que le journal binaire (binlog), le journal des erreurs, le journal des requêtes, le journal des requêtes lentes, etc. De plus, le moteur de stockage InnoDB fournit également deux types de journaux : le journal redo (redo log) et annuler le journal (retourner le journal). Ici, nous allons nous concentrer sur le moteur InnoDB et analyser les trois types de journaux redo, de journaux de restauration et de journaux binaires.

Redo log (redo log)

Le redo log (redo log) est le journal de la couche moteur InnoDB Il est utilisé pour enregistrer les changements de données provoqués par les opérations de transaction et enregistre la modification physique des pages de données.

La fonction de refaire le journal est en fait facile à comprendre, permettez-moi d'utiliser une analogie. La modification des données dans la base de données est comme un article que vous avez écrit. Que se passe-t-il si l'article est perdu un jour ? Pour éviter ce malheureux événement, lors de la rédaction d'un article, nous pouvons tenir un petit carnet pour enregistrer chaque modification, et enregistrer quand et quel type de modifications ont été apportées à une certaine page. C'est le journal de rétablissement.

Le moteur InnoDB met à jour les données en écrivant d'abord l'enregistrement de mise à jour dans le journal redo, puis en mettant à jour le contenu du journal sur le disque lorsque le système est inactif ou selon la stratégie de mise à jour définie. Il s'agit de la technologie dite d'écriture anticipée (Write Ahead logging). Cette technologie peut réduire considérablement la fréquence des opérations d'E/S et améliorer l'efficacité de l'actualisation des données.

Vinage des données sales

Il convient de noter que la taille du journal de rétablissement est fixe Afin d'écrire en continu les enregistrements de mise à jour, deux positions d'indicateur sont définies dans le journal de rétablissement, checkpoint et write_pos, qui représentent respectivement la position où. l'effacement est enregistré et la position où l'écriture est enregistrée. Le diagramme d'écriture des données du journal redo est visible dans la figure ci-dessous.

Lorsque le drapeau write_pos atteint la fin du journal, il passera de la fin à la tête du journal pour l'écriture de recirculation. Par conséquent, la structure logique du redo log n’est pas linéaire, mais peut être considérée comme un mouvement circulaire. L'espace entre write_pos et checkpoint peut être utilisé pour écrire de nouvelles données. L'écriture et l'effacement sont effectués en avant et en arrière dans un cycle.

Lorsque write_pos rattrape le point de contrôle, cela signifie que le journal de rétablissement est plein. Pour le moment, vous ne pouvez pas continuer à exécuter de nouvelles instructions de mise à jour de base de données. Vous devez d'abord arrêter et supprimer certains enregistrements, puis exécuter des règles de point de contrôle pour libérer de l'espace inscriptible.

Règles du point de contrôle : une fois le point de contrôle déclenché, les pages de données sales et les pages de journal sales dans le tampon seront vidées sur le disque.

Données sales : font référence aux données de la mémoire qui n'ont pas été vidées sur le disque.

Le concept le plus important du redo log est le pool de tampons. Il s'agit d'une zone allouée en mémoire, qui contient le mappage de certaines pages de données sur le disque et sert de tampon pour accéder à la base de données.

Lorsqu'une demande de lecture de données est faite, elle déterminera d'abord s'il y a un succès dans le pool tampon. S'il y a un échec, elle sera récupérée sur le disque et placée dans le pool tampon

 ; Lorsqu'une demande d'écriture de données est faite, elle sera écrite en premier. Pool de tampons, les données modifiées dans le pool de tampons sont périodiquement vidées sur le disque. Ce processus est également appelé brossage.

Par conséquent, lorsque les données sont modifiées, en plus de modifier les données dans le pool de tampons, l'opération sera également enregistrée dans le journal redo ; lorsque la transaction est soumise, les données seront vidées en fonction des enregistrements du journal redo ; . Si MySQL tombe en panne, les données du journal redo peuvent être lues lors du redémarrage et la base de données peut être restaurée, garantissant ainsi la durabilité des transactions et rendant la base de données sécurisée contre les crashs.

Vinage du journal sale

En plus du vidage des données sales mentionné ci-dessus, en fait, lorsque le journal redo est enregistré, afin d'assurer la persistance du fichier journal, il est également nécessaire d'écrire les enregistrements du journal de la mémoire au processus de disque. Le journal de redo peut être divisé en deux parties. L'une est le buff de journalisation du cache qui existe dans la mémoire volatile, et l'autre est le fichier de journalisation du fichier de journalisation enregistré sur le disque.

Afin de garantir que chaque enregistrement peut être écrit dans le journal sur le disque, l'opération fsync du système d'exploitation sera appelée chaque fois que le journal dans le tampon de journalisation est écrit dans le fichier de journalisation.

Fonction fsync : incluse dans le fichier d'en-tête du système UNIX #include , utilisée pour synchroniser toutes les données de fichiers modifiées dans la mémoire avec le périphérique de stockage.

Pendant le processus d'écriture, il doit également passer par le tampon os de l'espace noyau du système d'exploitation. Le processus d'écriture du journal redo est visible dans la figure ci-dessous.

processus de vidage du journal redo

Journal binaire (binlog)

Le journal binaire binlog est un journal de la couche de service et est également appelé journal d'archive. Binlog enregistre principalement les modifications dans la base de données, y compris toutes les opérations de mise à jour de la base de données. Toutes les opérations impliquant des modifications de données doivent être enregistrées dans le journal binaire. Par conséquent, binlog peut facilement copier et sauvegarder des données, il est donc souvent utilisé pour la synchronisation des bibliothèques maître-esclave.

Le contenu stocké dans le binlog ici semble être très similaire au redo log, mais ce n'est pas le cas. Le redo log est un journal physique, qui enregistre les modifications réelles apportées à certaines données ; tandis que le binlog est un journal logique, qui enregistre la logique originale de l'instruction SQL, telle que "donner le champ de la ligne avec ID=2". Ajoutez 1". Le contenu du journal binlog est binaire. Selon les paramètres de format du journal, il peut être basé sur des instructions SQL, sur les données elles-mêmes ou sur un mélange des deux. Les enregistrements généralement utilisés sont des instructions SQL.

Ma compréhension personnelle des concepts de physique et de logique ici est la suivante :

Le journal physique peut être considéré comme les informations de modification sur la page de données dans la base de données réelle. Il ne valorise que le résultat et ne se soucie pas. "de quelle manière" cela est provoqué. Ce résultat est obtenu ;

Les journaux logiques peuvent être considérés comme des changements de données provoqués par une certaine méthode ou opération, et les opérations logiques sont stockées.

Dans le même temps, le journal redo est basé sur la récupération après crash pour garantir la récupération des données après un crash de MySQL ; tandis que le binlog est basé sur une récupération à un moment précis pour garantir que le serveur peut récupérer les données en fonction de points temporels ou sauvegarder les données. .

En fait, MySQL n'avait pas de journal de rétablissement au début. Parce qu'au début MySQL n'avait pas de moteur InnoDB, le moteur intégré était MyISAM. Binlog est un journal de couche de service, il peut donc être utilisé par tous les moteurs. Cependant, les journaux binlog à eux seuls ne peuvent fournir que des fonctions d'archivage et ne peuvent pas fournir de fonctionnalités de sécurité en cas de crash. Par conséquent, le moteur InnoDB utilise une technologie apprise d'Oracle, à savoir le redo log, pour obtenir des fonctionnalités de sécurité en cas de crash. Voici une comparaison des caractéristiques du redo log et du binlog respectivement :

Comparaison des caractéristiques du redo log et du binlog

Lorsque MySQL exécute les instructions de mise à jour, la lecture et l'écriture du redo log et du binlog sont impliquées. Le processus d'exécution d'une instruction de mise à jour est le suivant :

Processus d'exécution de l'instruction de mise à jour MySQL

Comme le montre la figure ci-dessus, lorsque MySQL exécute l'instruction de mise à jour, il analyse et exécute l'instruction dans la couche de service, extrait et stocke les données dans la couche moteur ; en même temps, dans le service La couche écrit le binlog et écrit le redo log dans InnoDB.

De plus, il y a deux étapes de soumission lors de l'écriture du redo log. L'une est l'écriture de l'état de préparation avant l'écriture du binlog, et la seconde est l'écriture de l'état de validation après l'écriture du binlog.

La raison pour laquelle une telle soumission en deux étapes est organisée est naturellement raisonnable. Nous pouvons maintenant supposer qu'au lieu d'utiliser la soumission en deux phases, nous adoptons la soumission « en une seule phase », c'est-à-dire soit écrire d'abord le journal de rétablissement, puis écrire le journal binaire, soit écrire d'abord le journal binaire, puis écrire le journal de rétablissement. La soumission de ces deux manières entraînera une incohérence entre l'état de la base de données d'origine et l'état de la base de données restaurée.

Écrivez d'abord le journal de rétablissement, puis écrivez le journal binaire :

Après avoir écrit le journal de rétablissement, les données ont une capacité de sécurité en cas de crash à ce moment-là, de sorte que le système tombe en panne et les données seront restaurées à l'état où elles étaient avant le début de la transaction. Cependant, si le système plante lorsque le journal redo est terminé et avant que le journal binaire ne soit écrit, le système plante. Pour le moment, binlog n'enregistre pas l'instruction de mise à jour ci-dessus, ce qui entraîne l'absence de l'instruction de mise à jour ci-dessus lorsque binlog est utilisé pour sauvegarder ou restaurer la base de données. Par conséquent, les données de la ligne id=2 ne sont pas mises à jour.

Le problème de l'écriture du redo log d'abord, puis du binlog

Écrivez d'abord le binlog, puis du redo log :

Après l'écriture du binlog, toutes les instructions sont enregistrées, elles peuvent donc être copiées ou restaurées via binlog Les données dans la ligne id=2 dans la base de données sera mise à jour en a=1. Cependant, si le système tombe en panne avant l'écriture du journal redo, la transaction enregistrée dans le journal redo sera invalide, ce qui entraînera la non mise à jour des données de la ligne id=2 dans la base de données réelle.

Le problème de l'écriture d'abord du binlog puis du redo log

On peut voir que la soumission en deux étapes vise à éviter les problèmes ci-dessus et à rendre cohérentes les informations enregistrées dans binlog et redo log.

Journal de restauration (journal d'annulation)

Le journal de restauration est également un journal fourni par le moteur InnoDB. Comme son nom l'indique, la fonction du journal de restauration est de restaurer les données. Lorsqu'une transaction modifie la base de données, le moteur InnoDB enregistrera non seulement le journal de rétablissement, mais générera également le journal d'annulation correspondant ; si l'exécution de la transaction échoue ou si un rollback est appelé, provoquant l'annulation de la transaction, les informations contenues dans le journal d'annulation ; peut être utilisé pour restaurer les données jusqu'à ce qu'elles étaient avant la modification.

Mais l'annulation du journal est différente du rétablissement du journal. Il s'agit d'un journal logique. Il enregistre les informations liées à l'exécution des instructions SQL. Lorsqu'une restauration se produit, le moteur InnoDB fera le contraire du travail précédent en fonction des enregistrements du journal d'annulation. Par exemple, pour chaque opération d'insertion de données (insertion), une opération de suppression de données (suppression) sera effectuée lors de la restauration ; pour chaque opération de suppression de données (suppression), une opération d'insertion de données (insertion) sera effectuée lors de la restauration ; Opération de mise à jour (mise à jour), lors de la restauration, une opération de mise à jour inversée des données (mise à jour) sera effectuée pour modifier les données. Le journal d'annulation a deux fonctions, l'une consiste à fournir une restauration et l'autre à implémenter MVCC.

3. Réplication maître-esclave

Le concept de réplication maître-esclave est très simple : copier une base de données identique à partir de la base de données d'origine est appelée la base de données maître, et la base de données copiée est appelée. la base de données esclave. La base de données esclave synchronisera les données avec la base de données maître pour maintenir la cohérence des données entre les deux.

Le principe de la réplication maître-esclave est en réalité implémenté via le bin log. Le journal du journal bin stocke toutes les instructions SQL dans la base de données. En copiant les instructions SQL dans le journal du journal bin, puis en exécutant les instructions, la base de données esclave et la base de données principale peuvent être synchronisées.

Le processus de réplication maître-esclave est visible dans la figure ci-dessous. Le processus de réplication maître-esclave est principalement effectué par trois threads. Un thread d'envoi s'exécute sur le serveur maître et est utilisé pour envoyer les journaux binlog au serveur esclave. Il existe deux threads d'E/S et threads SQL supplémentaires en cours d'exécution sur le serveur esclave. Le thread d'E/S est utilisé pour lire le contenu du journal binlog envoyé par le serveur principal et le copier dans le journal de relais local. Le thread SQL est utilisé pour lire les instructions SQL sur les mises à jour des données dans le journal de relais et les exécuter pour assurer la cohérence des données entre les bibliothèques maître et esclave.

Principe de la réplication maître-esclave

La raison pour laquelle la réplication maître-esclave doit être mise en œuvre est en fait déterminée par le scénario d'application réel. Les avantages que la réplication maître-esclave peut apporter sont les suivants :

1. Réaliser une sauvegarde hors site des données via la réplication. Lorsque la base de données maître tombe en panne, la base de données esclave peut être commutée pour éviter la perte de données.

2. L'architecture peut être étendue lorsque le volume d'activité devient plus important et que la fréquence d'accès aux E/S est trop élevée, le stockage multi-bases de données peut être utilisé pour réduire la fréquence d'accès aux E/S du disque et améliorer les performances des E/S. d'une seule machine.

3. Il peut réaliser la séparation de la lecture et de l'écriture, afin que la base de données puisse prendre en charge une plus grande concurrence.

4. Implémentez l'équilibrage de charge du serveur en divisant la charge des requêtes clients entre le serveur maître et le serveur esclave.

Résumé

La base de données MySQL doit être considérée comme l'une des technologies que les programmeurs doivent maîtriser. Que ce soit pendant le processus de projet ou lors de l'entretien, MySQL est une connaissance de base très importante. Cependant, il y a vraiment trop de choses pour MySQL. Lorsque j'écrivais cet article, j'ai consulté beaucoup d'informations et j'ai constaté que plus je ne comprenais pas, plus je ne comprenais pas. C’est vraiment à la hauteur du dicton :

Plus vous en savez, plus vous n’en savez pas.

Cet article se concentre sur l'analyse des principes de base du système de transactions et de journalisation de base de MySQL d'un point de vue théorique. J'essaie d'éviter d'utiliser du code réel pour le décrire lors de sa description. Même cet article, composé de près de 10 000 mots et de près de 20 illustrations dessinées à la main, ne peut pas analyser pleinement l'étendue et la profondeur de MySQL.

Mais je crois que pour les débutants, ces théories peuvent vous donner une perception globale de MySQL et vous donner une compréhension plus claire de la question « qu'est-ce qu'une base de données relationnelle » et pour ceux qui maîtrisent MySQL Pour les grands, peut-être ; cet article peut également réveiller vos fondements théoriques sous-jacents perdus depuis longtemps, et il vous sera également utile pour vos entretiens ultérieurs.

Il n'y a pas de bien ou de mal absolu dans la technologie. Veuillez me pardonner s'il y a des erreurs dans l'article et n'hésitez pas à en discuter avec moi. La pensée indépendante est toujours plus efficace que l’acceptation passive.

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!