Mysqldump incomplet

J'essaie d'exécuter mysqldump pour créer un instantané de base de données, et je constate qu'il s'arrêtera au hasard à mi-chemin, sans signaler aucune erreur. Ma base de données est relativement petite (environ 100 Mo) et utilise InnoDB.

Je le lance comme:

mysqldump --force --single-transaction --quick --user myuser --password=mypass -h mydatabasehost mydb > /tmp/snapshot.sql

Vérification des rapports de code de sortie 0.

Ma version est: mysqldump Ver 10.13 Distrib 5.1.52, pour redhat-linux-gnu (i386)

J'ai vu des articles similaires et même un rapport de bogue officiel , mais aucune des solutions ne semble s'appliquer.

Comment faire pour que mysqldump prenne un instantané complet de la base de données?

EDIT: Ma base de données réside actuellement sur le RDS d'Amazon.

Cela peut avoir été un problème avec le fait de max_allowed_packetne pas être réglé suffisamment haut sur le client (ie mysqldump) et le serveur (ie Amazon RDS). Je l'ai réglé à 500M sur les deux et cela semble avoir résolu le problème.

Étant donné que les tableaux de schéma d'informations d'InnoDB ne donnent que des estimations du nombre de lignes, il est difficile de dire si mon instantané inclut vraiment tout ce qui provient de RDS. Toutes les tables sont là, mais le nombre de lignes diffère. Je mettrai à jour avec une réponse plus définitive lorsque j'aurai le temps de rédiger une analyse plus approfondie.

As-tu essayé?

mysqldump --compress --add-drop-table data --routines --events  --comments --extended-insert -h {host} -u {user} -p {database} > dbdump.sql

C'est simple comme je le fais toujours sans aucun problème. Fondamentalement, en faisant le vidage de cette façon, vous obtenez tout ce que vous avez (données, objets et parfois des commentaires précieux) à un certain moment en ignorant les transactions non engagées.

Pour autant que je sache, la documentation mysql --single-transaction échouera si une lecture est effectuée sur la table pendant le vidage. Quel est le résultat lors de l'exécution sans "--force --single-transaction --quick"?

Il est tout à fait possible que la table soit corrompue. Je ne veux pas dire que les données et / ou les pages d'index sont endommagées. Il pourrait y avoir quelque chose de très simple qui est cassé.

J'ai récemment rencontré un problème avec un script de sauvegarde sur un serveur esclave lorsque j'ai mis en parallèle plusieurs bases de données mysqldumped. L'exécution de mysqldump sur l'une des bases de données a entraîné un très petit mysqldump. La DB avait plus de 80 tables. Cependant, mysqldump s'est arrêté à la cinquième table de la base de données. Lorsque j'ai couru SHOW CREATE TABLE tblname\Gsur la table sur l'esclave, j'ai eu l'erreur "Table non trouvée". Lorsque j'ai couru SHOW CREATE TABLE tblname\Gsur le Master, la description de la table s'est affichée comme prévu.

Ce qui s'est passé était un peu fou: un client a demandé une restauration de table et un ingénieur a restauré le fichier .ibd de la table InnoDB à partir d'une sauvegarde sur disque. L'ID d'espace disque logique du fichier .ibd (qui était de 25) ne correspondait pas à l'ID d'espace disque logique enregistré dans ibdata1 (qui était 28).

J'ai résolu le problème en arrosant l'esclave, en vidant mysqld le maître et en configurant la réplication à partir de zéro. Heureusement, les données et l'index spave ont totalisé 7 Go. Ainsi, le processus de restauration n'était pas un gros problème.

MORALE DE L'HISTOIRE

Le problème de base est que mysqldump ne signale pas d'erreur sur un InnoDB lorsque l'ID de l'espace de table est incorrect. Lorsqu'un mysqldump se termine et ne sauvegarde pas chaque table par ordre alphabétique, cela indique qu'il s'est terminé par une erreur et l'a fait sans imprimer de message d'erreur.

Vérifiez pour vous assurer

• vous pouvez afficher la structure de la table en utilisant SHOW CREATE TABLE
• vous pouvez tout interroger sur une table à partir de INFORMATION_SCHEMA.TABLES

Ce qui suit est juste un remue-méninges sur mysqldump et InnoDB:

Réfléchissez au comportement de mysqldump par rapport à une table InnoDB. S'il y a des pages sales dans le pool de tampons InnoDB appartenant à une table que vous videz, les pages sales de cette table doivent être vidées sur le disque avant de SELECT /* SQL_NO_CACHE */pouvoir être exécutées contre.

Puisque vous utilisez Amazon RDS, mon sentiment profond est que votre base de données se trouve dans une infrastructure multi-locataire (n'hésitez pas à corriger cette déclaration si je simplifie à l'excès). D'autres bases de données peuvent utiliser un pool de mémoire tampon InnoDB partagé, un fichier de métadonnées partagé (ibdata1) et un espace de table partagé (ibdata1 si innodb_file_per_table est désactivé).

Il peut également y avoir une redondance de la base de données en cours, ce qui pourrait affecter MVCC par rapport à la base de données, même s'il s'agit d'un petit ensemble de données.

Vous voudrez peut-être augmenter innodb_lock_wait_timeout (par défaut 50 secondes) dans votre session mysqldump pour voir si cela a un effet sur Amazon RDS (ou demander à Amazon d'augmenter cette limite). Essayez également d'expérimenter le dumping de tables individuelles.

MISE À JOUR 2011-11-14 17:58 EDT

Essayez d'exécuter cela dans votre session DB (définissez-le sur deux minutes):

SET innodb_lock_wait_timeout = 120;