我使用以下命令备份MySQL数据库已有好几年了：
mysqldump myDatabaseName -u root > myBackupFile.sql
备份似乎工作正常......
然后我想将其中一个备份恢复到另一个命名数据库，所以我做了：
mysql myNewDatabaseName -u root < myBackupFile.sql
我得到了一些关于日志文件大小的错误，所以我停止了Mysql并删除了日志文件并在my.ini文件中设置了以下参数并重新启动了mysql。
innodb_log_file_size=64M
innodb_log_buffer_size=8M
恢复现在完成且没有错误，但是从不恢复包含blob的三个表中的一个。
我的max-allowed-packet设置为32M
数据库备份大小约为2.2 GB，该大小的大部分位于不恢复的表中。如果我在恢复的数据库上运行mysqldump，则大小为185 MB。
我现在尝试使用选项mysqldump执行--hex-blob，但我还没有尝试恢复该文件（3.9 GB）。
我真的需要有一种防弹方式来备份和恢复，因为我现有的备份看起来毫无价值。我特别担心它“无声地失败”，据我所知没有错误日志条目。
环境是windows server 2003 sp2
任何帮助表示赞赏！
乔治
答案 0 :(得分：4)
我设法使用以下mysqldump命令备份并恢复blob：
mysqldump --opt --skip-extended-insert --max_allowed_packet=128M -u root myDB > filename
不确定它是在命令行上指定max_allowed_packet还是在skip-extended-insert指定了这个技巧。
我假设我的max_allowed_packet使用了32M，但我认为在mysql配置文件中它位于[mysqld]部分，因此可能不适用于转储。
我仍然不明白为什么转储或恢复都没有错误。
答案 1 :(得分：2)
mysqldump --skip-extended-insert可以正常工作，但在恢复时可以将性能降低100倍，这使它不是一个可行的选择。
进行备份时，max_allowed_packet会忽略mysqldump（design？）实际补码为net_buffer_length。因此，请确保您的max_allowed_packet大于net_buffer_length，并且它应该有效。如：
mysqldump -u root --net_buffer_length=100k oldDB > backup.sql
mysql -u root --max_allowed_packet=10M newDB < backup.sql