Parlons du verrouillage global MySQL

Cet article vous apporte des connaissances pertinentes sur mysql, qui présente principalement des problèmes liés aux verrous globaux. Les verrous globaux verrouillent l'intégralité de la base de données. Après avoir ajouté un verrou en lecture à la base de données, aucune autre requête ne peut ajouter un verrou en écriture à la base de données. Examinons-le ensemble, j'espère que cela sera utile à tout le monde.

Apprentissage recommandé : Tutoriel vidéo MySQL

L'intention initiale de la conception d'une base de données est de traiter les problèmes de concurrence. En tant que ressource partagée par plusieurs utilisateurs, lorsqu'un accès simultané se produit, la base de données doit contrôler raisonnablement les règles d'accès. de la ressource. Le verrou est une structure de données importante utilisée pour mettre en œuvre cette règle d'accès.

Publions d'abord un schéma de la classification générale des verrous

Selon la portée du verrouillage, les verrous dans MySQL peuvent être grossièrement divisés en verrous globaux, verrous de table et verrous de ligne. Nous apprendrons principalement ces types de verrous en premier. Dans cet article, nous découvrirons les verrous globaux.

Verrouillage global

Le verrouillage global consiste à verrouiller l'intégralité de la base de données. Après avoir ajouté un verrou en lecture à la base de données, aucune autre requête ne peut ajouter de verrous en écriture à la base de données. Lorsque nous ajoutons un verrou en écriture à la base de données, aucune autre requête ultérieure ne peut ajouter de verrous en lecture ou en écriture à la base de données.

FTWRL

MySQL fournit une méthode pour ajouter un verrou de lecture global, Flush tables avec verrou de lecture (FTWRL). Lorsque nous devons mettre la bibliothèque entière en lecture seule, nous pouvons utiliser cette commande. Ensuite, les instructions suivantes des autres threads seront bloquées : les instructions de mise à jour des données (ajouter, supprimer, modifier), les instructions de définition des données (y compris la création de tables). , modification des structures de table, etc.) et update Une instruction de validation pour une transaction de classe.

Scénarios d'utilisation des verrous globaux

Scénarios d'utilisation des verrous globaux : Effectuez une sauvegarde logique de l'ensemble de la base de données. La sauvegarde logique consiste à sélectionner chaque table de la base de données entière et à l'enregistrer sous forme de texte. C'est-à-dire que le verrouillage global n'est utilisé que lors de la sauvegarde de données maître-esclave ou de l'importation et de l'exportation de données.

Alors pourquoi avez-vous besoin d'un verrouillage global ?

Parce que lorsque nous effectuons une sauvegarde de données ou que nous importons et exportons des données, si des données peuvent être ajoutées, supprimées et modifiées en même temps pendant cette période, une incohérence des données se produira.

Dans le passé, il existait un moyen d'utiliser le FTWRL mentionné ci-dessus pour garantir qu'aucun autre thread ne mettrait à jour la base de données pendant la sauvegarde. Remarque : pendant le processus de sauvegarde, l'intégralité de la bibliothèque est entièrement en lecture seule.

Étant donné que le verrouillage global est orienté vers cette base de données, l'ajout d'un verrouillage global semble très dangereux :

• Si nous sauvegardons sur la base de données principale, les mises à jour ne peuvent pas être effectuées pendant la période de sauvegarde, ce qui signifie que pratiquement toutes les activités sont suspendues.
• Si nous sauvegardons sur la base de données esclave, le binlog synchronisé à partir de la base de données maître pendant la période de sauvegarde ne peut pas être exécuté, ce qui entraînera un retard maître-esclave et une incohérence des données.

Comment éviter le verrouillage

Étant donné que l'ajout d'un verrouillage global a un impact si important, pouvons-nous éviter le verrouillage ?

Grâce à l'introduction ci-dessus, nous savons que le verrouillage vise à résoudre le problème de l'incohérence des données. Ainsi, tant que nous pouvons résoudre le problème de l'incohérence des données, nous n'avons pas besoin d'ajouter un verrou global. Il existe une telle idée : si nous enregistrons un journal des opérations lorsque nous démarrons la sauvegarde des données, l'ajout, la suppression, la modification et l'interrogation de la base de données seront autorisés sans verrouillage pendant le processus de sauvegarde, et pendant le processus de sauvegarde, les enregistrements d'opérations d'ajouts , les suppressions, les modifications et les requêtes seront enregistrées dans un seul fichier journal, une fois notre sauvegarde terminée, nous exécuterons toutes les opérations dans le fichier journal pendant cette période. Cela garantit la cohérence des données avant et après la sauvegarde.

En résumé, sans verrouillage, les données de sauvegarde et les données principales ne sont pas à un instant logique, et cette vue est logiquement incohérente. Si nous nous assurons que les points de temps logiques sont cohérents, c'est-à-dire que les vues logiques sont cohérentes, nous pouvons garantir la cohérence des données. À partir de là, nous pensons au niveau d'isolement des transactions que nous avons appris auparavant. L'ouverture d'une transaction sous le niveau d'isolement répétable est une bonne chose. vue cohérente.

Il existe un mécanisme dans InnoDB, le moteur par défaut de MySQL, pour assurer la cohérence des données. Le moteur InnoDB dispose d'une fonction de version d'instantané de données. Cette fonction est appelée MVCC car MVCC conserve des instantanés des versions historiques. Chaque instantané correspond à un numéro de version de transaction. Lorsque nous sauvegardons les données, nous demanderons un numéro de version de transaction lors de la lecture. Pour récupérer des données, il vous suffit de lire les données avec un numéro de version de transaction plus petit que le vôtre.

–verrouillage de commande à transaction unique

L'outil de sauvegarde logique officiel est mysqldump. Lorsque mysqldump utilise le paramètre –single-transaction, une transaction sera démarrée avant l'importation des données pour garantir l'obtention d'une vue cohérente. Grâce à la prise en charge de MVCC, les données peuvent être mises à jour normalement pendant ce processus.

Le rôle du paramètre --single-transaction est de définir le niveau d'isolement de la transaction sur lecture répétable, c'est-à-dire REPEATABLE READ. Cela garantit que toutes les mêmes requêtes dans une transaction lisent les mêmes données, ce qui garantit à peu près cela pendant. pendant la période de vidage, si d'autres threads du moteur InnoDB modifient les données de la table et les soumettent, cela n'aura aucun impact sur les données du thread de vidage.

Et définissez AVEC INSTANTANÉ COHÉRENT au niveau instantané. Imaginez que s'il ne s'agit que d'une lecture répétable, alors avant que les données ne soient vidées au début de la transaction, d'autres threads modifient et soumettent les données, alors le résultat de la première requête à ce moment est le résultat soumis par d'autres threads, et AVEC CONSISTENT SNAPSHOT peut garantir que lorsqu'une transaction est démarrée, le résultat de la première requête est les données A au début de la transaction. Même si d'autres threads modifient ses données en B à ce moment, le résultat de la requête est toujours A.

La méthode de transaction unique s'applique uniquement aux bibliothèques qui utilisent des moteurs de transaction pour toutes les tables. Dans le processus mysqldump, l'ajout de --single-transaction peut garantir que les données InnoDB sont complètement cohérentes. Pour les moteurs comme MyISAM qui ne prennent pas en charge les transactions, s'il y a des mises à jour pendant le processus de sauvegarde, seules les données les plus récentes peuvent toujours être obtenues. Cela détruit la cohérence de la sauvegarde. À l’heure actuelle, un verrou global est toujours nécessaire, nous devons donc toujours utiliser la commande FTWRL.

Paramètre en lecture seule

Nous pouvons également nous poser cette question, puisque toute la bibliothèque doit être en lecture seule, pourquoi n'utilisons-nous pas set global readonly = true ?

Il est vrai que la méthode readonly peut également mettre la bibliothèque entière en lecture seule, mais il est quand même recommandé d'utiliser la méthode FTWRL, principalement pour deux raisons :

• Dans certains systèmes, la valeur en lecture seule sera utilisé pour d'autres logiques, telles que Déterminer si une base de données est la base de données principale ou de secours. Par conséquent, la modification des variables globales a un impact plus important.
• Il existe des différences dans les mécanismes de gestion des exceptions. Si le client se déconnecte anormalement après l'exécution de la commande FTWRL, MySQL libérera automatiquement le verrou global et la bibliothèque entière reviendra à un état dans lequel elle pourra être mise à jour normalement.

Après avoir défini l'ensemble de la bibliothèque en lecture seule, si une exception se produit sur le client, la base de données restera en lecture seule, ce qui rendra l'ensemble de la bibliothèque dans un état non inscriptible pendant une longue période, avec un risque élevé.

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!