Mysqldump est un utilitaire client utilisé pour effectuer des sauvegardes logiques de la base de données MySQL. Cet outil de migration populaire est utile pour divers cas d'utilisation de MySQL tels que :
- Sauvegarde et restauration des bases de données.
- Migration de données d'un serveur à un autre.
- Migration des données entre différents fournisseurs de services MySQL gérés
- Migrer des données entre différentes versions de MySQL.
Mysqldump fonctionne en lisant les objets de la base de données source et en générant un ensemble d'instructions SQL qui sont stockées dans un fichier de vidage. En relisant ces instructions sur le serveur de base de données de destination, les données d'origine sont reconstruites. Étant donné que ce modèle utilise la lecture de toute la base de données, puis essentiellement la reconstruction, le vidage et la restauration sont des opérations chronophages pour une grande base de données. Le processus peut même devenir fastidieux si vous rencontrez des erreurs lors du vidage ou de la restauration, car cela peut vous amener à résoudre les problèmes et à réexécuter les opérations. C'est pourquoi il est important de bien planifier avant de commencer l'activité de vidage et de restauration.
Dans cette série de blogs en deux parties, nous abordons certains des aspects courants que vous devez gérer en amont pour garantir la réussite de l'activité de vidage et de restauration. Dans la première partie, nous nous concentrons sur les prérequis dont vous devez faire attention lors de l'importation des données de la table MySQL et dans la deuxième partie, nous expliquerons comment gérer l'importation pour les objets et vues de programme stockés.
1. Espace requis
Tout d'abord, il est important de vous assurer que le volume de votre base de données de destination dispose de suffisamment d'espace pour contenir les données importées. Plus précisément, vous devez être prudent si les journaux binaires sont activés sur votre base de données MySQL de destination, car les journaux binaires générés lors de l'importation des données peuvent prendre une taille presque égale à celle des données elles-mêmes. Les journaux binaires sont nécessaires si vous souhaitez restaurer vos données sur un serveur et souhaitez que cela soit répliqué. Dans de tels cas, il est judicieux de prévoir une taille de destination supérieure à deux fois la taille de la base de données source.
Il est également important de s'assurer qu'un espace suffisant est disponible sur le volume où vous générez le fichier de sortie mysqldump. Sans ces précautions, vous risquez de voir votre vidage ou votre restauration échouer en raison d'un espace insuffisant après une longue période d'exécution, ce qui représente une perte de temps et d'efforts productifs.
2. SQL_mode
les paramètres sql_mode pour le serveur MySQL déterminent la syntaxe de l'instruction SQL et les vérifications de validation des données que le serveur effectue pour les opérations. Il est important de s'assurer du sql_mode des serveurs MySQL source et de destination sont compatibles entre eux, ou vous pouvez rencontrer des échecs lors de la restauration du vidage que vous avez effectué. Démontrons cela avec un exemple.
Disons que vous avez une table sur votre source qui a une colonne de date ayant des entrées comme des dates nulles :
mysql> show create table sched; --------------------------------------------------------+ | Table | Create Table | --------------------------------------------------------+ | sched | CREATE TABLE `sched` ( `id` int(11) DEFAULT NULL, `ts` date DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | +-------+--------------------------------------------------------------------------------------------------------------------- mysql> select * from sched; +------+------------+ | id | ts | +------+------------+ | 1 | 2020-01-12 | | 2 | 0000-00-00 | +------+------------+
Supposons le strict sql_mode (et NO_ZERO_DATE ) est désactivé sur la source, mais activé sur la destination - la restauration de ces lignes entraînera des échecs tels que :
ERROR 1292 (22007) at line 40: Incorrect date value: '0000-00-00' for column 'ts’' at row 2
Vous rencontrerez généralement de tels problèmes si vous effectuez un vidage compact en activant l'option compact dans le cadre de votre mysqldump.
Si compact est désactivé (ce qui est le cas par défaut), vous ne serez pas confronté à ce problème car mysqldump génère l'instruction conditionnelle suivante dans le cadre du vidage :
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
Cela signifie que lors de la restauration sql_mode est défini sur 'NO_AUTO_VALUE_ON_ZERO' avant de restaurer les données de la table afin que la restauration se passe bien.
3. Unique_checks et foreign_key_checks
Par défaut (si vous n'utilisez pas l'option –compact), mysqldump définit également ce qui suit :
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
Comme expliqué ici, vous pouvez accélérer l'opération de restauration en désactivant temporairement les contrôles d'unicité pendant la session. Pour les grandes tables, cela permet d'économiser beaucoup d'E/S disque car InnoDB peut utiliser son tampon de modification pour écrire des enregistrements d'index secondaires dans un lot.
Si vous avez FOREIGN KEY contraintes dans vos tables, vous pouvez accélérer l'opération de restauration de table en désactivant les vérifications de clé étrangère pendant la durée de la session de restauration :pour les grandes tables, cela peut économiser beaucoup d'E/S disque.
Désactivation de FOREIGN_KEY_CHECKS aidera également à éviter les erreurs dues aux vérifications des contraintes de clé étrangère lors de l'opération de restauration. Chaque fois qu'une table avec une contrainte de clé étrangère est créée, MySQL s'attend à ce que la table parent à laquelle la clé étrangère fait référence existe déjà. C'est un problème car l'utilitaire mysqldump vide les tables dans l'ordre alphabétique. Prenons un exemple pour le démontrer.
Sur la base de données source, nous avons deux tables :
CREATE TABLE `solution_table` ( `num1` int(11) NOT NULL, `num2` int(11) DEFAULT NULL, PRIMARY KEY (`num1`)); CREATE TABLE `ref_table` ( `key` int(11) DEFAULT NULL, `ref_num` int(11) DEFAULT NULL, KEY `ref_num` (`ref_num`), CONSTRAINT `ref_num_ibfk_1` FOREIGN KEY (`ref_num`) REFERENCES `solution_table` (`num1`) )
Le tableau ref_table a une contrainte de clé étrangère qui fait référence à la solution_table . Basé sur l'ordre alphabétique, mysqldump vide d'abord le contenu de ref_table . Lorsqu'il est rejoué au moment de la restauration, il échouera avec l'erreur :
ERROR 1215 (HY000) at line 50: Cannot add foreign key constraint -
Ce qui se produit lors de l'exécution de l'instruction de création de table pour ‘ref_table’ .
En résumé, soyez conscient des problèmes que vous pouvez rencontrer si vous spécifiez --compact lors de l'exécution de mysqldump.
4. Privilèges requis pour exécuter mysqldump
Le privilège minimum requis par mysqldump pour vider une base de données est SELECT sur cette base de données.
Cependant, si votre base de données a des vues, vous aurez également besoin des autorisations SHOW VIEW, car mysqldump vide toujours les vues avec les tables de la base de données. Supposons que vous n'ayez pas SHOW VIEW permissions, alors mysqldump échouera avec :
mysqldump: Couldn't execute 'show create table `ivew`': SHOW VIEW command denied to user ‘dumpuser’@'172.31.18.79' for table 'iview' (1142)
Un autre point d'intérêt est si votre dumpuser a SELECT autorisations uniquement sur une table particulière de la base de données, mysqldump ne videra les données que pour cette table particulière et ignorera automatiquement toutes les autres tables ou vues.
Veuillez donc vous assurer que l'utilisateur exécutant mysqldump dispose à l'avance de tous les privilèges appropriés afin d'éviter toute surprise ou échec ultérieur.
|
5. Max_allowed_packet
Le plus grand paquet de communication géré par mysql est déterminé par le paramètre max_allowed_packet . Dans le contexte de l'importation, un paquet de communication est une seule instruction SQL envoyée au serveur MySQL lors de la restauration OU une seule ligne envoyée au client lors du vidage.
La valeur par défaut de max_allowed_packet pour mysqldump est de 24 Mo. si mysqldump reçoit un paquet plus grand que cela, vous pouvez rencontrer l'erreur :
mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table `huge1` at row: 2.
Assurez-vous donc que mysqldump utilise la même valeur ou une valeur supérieure de max_allowed_packet qui est configuré sur l'instance MySQL source.
L'option peut être spécifiée avec le drapeau --max-allowed-packet=value lors de l'appel de mysqldump.
Lors de la restauration du vidage, assurez-vous que max_allowed_packet la taille de votre serveur de destination est suffisamment grande pour recevoir les paquets du fichier de vidage.
Sinon, lors de la restauration du dump, vous verrez un message d'erreur :
ERROR 2006 (HY000) at line 70: MySQL server has gone away
Cette erreur peut être un peu trompeuse car vous pouvez penser que le serveur MySQL s'est arrêté ou est tombé en panne. Mais cela signifie simplement que le serveur a reçu un paquet de plus grande taille que sa taille configurée de max_allowed_packet . Encore une fois, la meilleure pratique consiste à s'assurer que le max_allowed_packet la valeur de votre serveur de destination est la même que celle du serveur source. Il s'agit également d'un paramètre important qui peut être vérifié et défini de manière appropriée dès le départ, plutôt que de faire face aux erreurs ultérieurement.
Dans cette première partie de la série mysqldump, nous avons discuté des conditions préalables à une opération de vidage et de restauration réussie pour les grandes bases de données MySQL afin de vous aider à éviter les tentatives multiples et le temps improductif passé.
Dans la partie suivante, nous discuterons des meilleures pratiques pour importer les programmes et les vues stockés à partir de votre base de données MySQL.
