Explication détaillée des exemples de mysqldump

Certains environnements de production utilisent mysqldump --single-transaction pour effectuer une sauvegarde de base de données la nuit, et un collègue a effectué une opération de modification de table pendant la période de sauvegarde. Une partie de l'opération a réussi et une autre a échoué. Pourquoi ?

Le test a été exécuté sur MySQL 5.6.36, il y a une différence de version pour ce problème !

##======================================= === =================================###

Explication du paramètre de transaction unique dans mysqldump Pour :

Creates a consistent snapshot by dumping all tables in a
single transaction. Works ONLY for tables stored in
storage engines which support multiversioning (currently
only InnoDB does); the dump is NOT guaranteed to be
consistent for other storage engines.
 While a
--single-transaction dump is in process, to ensure a
valid dump file (correct table contents and binary log
position), no other connection should use the following
statements: ALTER TABLE, DROP TABLE, RENAME TABLE,
TRUNCATE TABLE, as consistent snapshot is not isolated
from them.
 Option automatically turns off --lock-tables.

La partie police rouge est le point clé, mais c'est un peu déroutant à voir, donc je ferais mieux de l'essayer.

Selon l'introduction de "Exploration de plusieurs options principales de Mysqldump", la commande mysqldump --single-transaction --master-data que nous exécutons pour la sauvegarde équivaut à exécuter le code suivant :

FLUSH TABLES;
FLUSH TABLES WITH READ LOCK;SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
START TRANSACTION WITH CONSISTENT SNAPSHOT;
SHOW MASTER STATUS;
UNLOCK TABLES;

SHOW TABLES LIKE 'xxx'SET OPTION SQL_QUOTE_SHOW_CREATE=1SHWO CREATE TABLE 'xxx'SHOW FIELDS FROM 'xxx'SHOW TABLE STATUS LIKE 'xxx'SELECT /*!40001 SQL_NO_CACHE */ * FROM  xxx

QUIT

Scénario 1 : lorsque mysqldump est démarré mais n'a pas été sauvegardé dans la table tb001, une autre session effectue une opération de modification sur la table tb001, puis mysqldump exporte la table tb001

L'opération de modification s'est terminée avec succès, mais l'opération mysqldump a échoué.

Scénario 2 : mysqldump démarre la sauvegarde et termine l'export de tb001 Lors de l'export d'autres tables, d'autres sessions effectuent des opérations de modification sur les tables

.

L'opération de modification de table est bloquée jusqu'à ce que mysqldump se termine ou se ferme après un échec.

Lors de l'utilisation de mysqldump pour sauvegarder, simulez l'environnement du scénario 2, le message d'erreur est :

mysqldump : Erreur 1412 : La définition de la table a changé, veuillez réessayer la transaction lors du dumping de la table `tb1002` à la ligne : 0

Afficher le fichier d'exportation, le contenu final est :

--
-- Dumping data for table `tb1002`--LOCK TABLES `tb1002` WRITE;/*!40000 ALTER TABLE `tb1002` DISABLE KEYS */;

Résumé :

paramètre de transaction unique La cohérence des données est obtenue via plusieurs versions d'Innodb, mais des opérations telles que ALTER TABLE, DROP TABLE, RENAME TABLE et TRUNCATE TABLE détruiront la cohérence des données et les deux opérations ne pourront pas être exécutées simultanément.

Si l'opération de modification de la table démarre dans le délai « après l'ouverture de mysqldump mais avant l'exportation des données de la table de modification », l'opération de modification de la table se termine avec succès, mais mysqldump échouera

; Si Si l'opération de modification de table démarre dans la période « mysqldum a exporté les données de la table de modification mais avant la fin de l'opération mysqldump », l'opération de modification de table est bloquée et mysqldum peut la terminer avec succès. L'opération de modification de table peut être exécutée normalement après. l'opération mysqldump est terminée.

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!