2010-08-15 23 views
10

Je suis la sauvegarde d'une base de données MySQL depuis plusieurs années avec la commande: mysqldump myDatabaseName -u root > myBackupFile.sqlComment restaurer de manière fiable MySQL blobs

Les sauvegardes ont semblé fonctionner correctement ...

Je voulais alors restaurer un des sauvegardes sur une autre base de données nommée donc je l'ai fait: mysql myNewDatabaseName -u root < myBackupFile.sql

J'ai eu quelques erreurs sur la taille du fichier journal si je me suis arrêté Mysql et enlevé les fichiers journaux et définissez les paramètres dans le fichier my.ini suivants et redémarré mysql.

innodb_log_file_size=64M

innodb_log_buffer_size=8M

La restauration complète maintenant sans erreur, mais l'une des trois tables qui contient blobs soit restauré.

Mon max-allowed-packet est réglé sur 32M

La taille de la sauvegarde de base de données est d'environ 2,2 Go la majorité de cette taille étant dans le tableau qui ne restaure pas. Si je lance un mysqldump sur la base de données restaurée, la taille est de 185 Mo.

J'ai maintenant essayé de faire un mysqldump avec l'option --hex-blob mais je n'ai pas encore essayé de restaurer ce fichier (3.9 GB).

J'ai vraiment besoin d'un moyen anti-bombe pour sauvegarder et restaurer car mes sauvegardes existantes semblent sans valeur. Je suis particulièrement préoccupé par le fait qu'il "échoue silencieusement" sans aucune entrée dans le journal des erreurs pour autant que je puisse voir.

L'environnement est Windows Server 2003 sp2

Toute aide appréciée!

George

+0

Les blobs sont-ils présents dans le fichier de vidage?Peut-être n'ont-ils jamais été sauvegardés et le processus de restauration a parfaitement fonctionné avec les données existantes. Max_packet affecte les données dans les deux sens. Si vous avez déversé avec une limite trop petite, les blobs peuvent avoir été supprimés ou tronqués. –

Répondre

4

J'ai réussi à sauvegarder et restaurer les blobs en utilisant la commande mysqldump suivante:

mysqldump --opt --skip-extended-insert --max_allowed_packet=128M -u root myDB > filename 

Je ne sais pas si elle est en spécifiant max_allowed_packet sur la ligne de commande ou le skip-extended-insert qui a fait l'affaire.

J'ai supposé que mon max_allowed_packet de 32M était utilisé, mais je pense que dans le fichier de configuration mysql il est dans la section [mysqld] et ne s'applique donc probablement pas à dump.

Je ne comprends toujours pas pourquoi je n'ai eu aucune erreur sur le vidage ou la restauration.

+0

mysqldump ignore max_allowed_packet. Lisez ce rapport de bogue pour essayer de comprendre si c'est par conception ou non: http://bugs.mysql.com/bug.php?id=9753 – Leopd

2

mysqldump --skip-extended-insert fonctionne mais peut réduire les performances de 100x lors de la restauration, ce qui ne constitue pas un choix viable.

Lorsque vous effectuez la sauvegarde, max_allowed_packet est ignoré par mysqldump (par design?) Le complément réel est net_buffer_length. Assurez-vous donc que votre max_allowed_packet est plus grand que votre net_buffer_length et que cela devrait fonctionner. Comme dans:

mysqldump -u root --net_buffer_length=100k oldDB > backup.sql 
mysql -u root --max_allowed_packet=10M newDB < backup.sql