J'essaie d'exécuter MySqldump pour créer un instantané de base de données, et je trouve qu'il arrêtera au hasard à mi-chemin, sans signaler une erreur. Ma base de données est relativement petite (environ 100 Mo) et utilise innoDB.
Je l'exécute 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 la suivante: mysqldump ver 10.13 Distrib 5.1.52, pour Redhat-Linux-Gnu (i386)
J'ai vu certains postes similaires et même n rapport de bogue officiel , mais aucune des solutions ne semble appliquer.
Comment obtenir MySqldump de prendre un instantané complet de la base de données?
EDIT: Ma base de données réside actuellement sur les RD de Amazon.
Cela peut avoir été un problème avec max_allowed_packet
ne pas être défini assez haut sur le client (c'est-à-dire mysqldump) et le serveur (I.e. Amazon RDS). Je fixe ceci à 500m sur les deux et cela semble pour avoir corrigé le problème.
Étant donné que les tables de schéma d'informations d'Innodb donnent uniquement des estimations du nombre de lignes, il est difficile de dire si mon instantané inclut vraiment tout de RDS. Toutes les tables sont là, mais la rangée compte diffère. Je vais mettre à jour avec une réponse plus définitive lorsque j'ai un peu de temps pour scripter une analyse plus approfondie.
Pour autant que je sache, la MySQL Docs --Single-transaction échouera si une lecture est effectuée sur la table pendant que vous dumping. Quel est le résultat lors de la course sans "--force - Single-transaction --Quick"?
Il est tout à fait possible que la table soit corrompue. Je ne veux pas dire que les pages de données et/ou d'index sont endommagées. Il pourrait y avoir quelque chose de très simple qui est cassé.
J'ai récemment connu un problème avec un script de sauvegarde sur un serveur esclave lorsque je parallèle plusieurs bases de données multiples mysqldump. Exécution de MySqldump sur l'une des bases de données aboutit à un très petit mysqldump. La DB avait plus de 80 tables. Cependant, le mysqldump s'est arrêté à la cinquième table de la DB. Quand j'ai couru SHOW CREATE TABLE tblname\G
Sur la table sur l'esclave, j'ai eu l'erreur "Table non trouvée". Quand j'ai couru SHOW CREATE TABLE tblname\G
Sur le maître, la description de la table 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 de disque. L'ID d'espace de table du fichier .ibd (qui était de 25) ne correspond pas à l'ID de table d'espacement enregistré dans IBDATA1 (qui était 28).
J'ai corrigé le problème en bloquant l'esclave, mysqldumping the maître et en configurant une réplication à partir de zéro. Heureusement, la spave de données et d'index a totalisé 7 Go. Ainsi, le processus RSTore n'était pas un gros problème.
MORALE DE L'HISTOIRE
Le problème de base est que MySqldump ne signale pas une erreur sur un InnoDB lorsque l'ID d'espace de table est incorrect. Lorsqu'une MySqldump se termine et ne vide pas toutes les tables dans l'ordre alphabétique, cela l'indique terminé par une erreur et l'a fait sans imprimer un message d'erreur.
Vérifiez pour vous assurer
SHOW CREATE TABLE
Ce qui suit est juste un peu de brainstorming sur mysqldump et InnoDB:
Pensez au comportement de MySqldump contre une table InnoDb. S'il y a des pages sales dans le pool de tampons InnoDb appartenant à une table que vous démarquez, les pages sales de la table doivent être rinçues sur le disque avant un SELECT /* SQL_NO_CACHE */
peut être exécuté contre elle.
Depuis que vous utilisez Amazon RDS, mon sentiment d'intestin est que votre base de données est dans une infrastructure multi-entreprises (n'hésitez pas à corriger cette déclaration si je suis trop simplifié). 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_ttable est désactivé).
Il peut également y avoir une certaine redondance de la base de données, ce qui pourrait affecter [~ # ~] MVCC [~ # ~] Contre la base de données, même s'il est un petit jeu 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 que Amazon augmente cette limite). Essayez également d'expérimenter des tables individuelles dumping.
Mise à jour 2011-11-14 17:58 EDT
Essayez d'exécuter cela dans votre session de base de données (la définit à deux minutes):
SET innodb_lock_wait_timeout = 120;