Как надежно восстановить MySQL blobs

Я поддерживаю базу данных 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

Теперь восстановление завершается без ошибок, но одна из трех таблиц, содержащих капли, никогда не восстанавливается.

Мой max-allowed-packet установлен в 32M

Размер резервной копии базы данных составляет около 2,2 ГБ, причем большая часть этого размера находится в таблице, которая не восстанавливается. Если я запустил mysqldump в восстановленной базе данных, размер составляет 185 МБ.

Теперь я попытался сделать mysqldump с опцией --hex-blob, но я еще не пытался восстановить этот файл (3.9 ГБ).

Мне действительно нужно иметь безопасный способ резервного копирования и восстановления, поскольку мои существующие резервные копии выглядят бесполезными. Я особенно обеспокоен тем, что он "терпит неудачу" без записей журнала ошибок, насколько я могу видеть.

Среда - это сервер Windows 2003 sp2

Любая помощь оценивается!

Джордж

Ответ 1

Мне удалось создать резервную копию и восстановить капли с помощью следующей команды mysqldump:

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] и, вероятно, не применим к дампу.

Я все еще не понимаю, почему у меня нет ошибок ни на дампе, ни на восстановлении.

Ответ 2

mysqldump --skip-extended-insert работает, но может снизить производительность на 100x при восстановлении, что делает его нецелесообразным выбором.

Когда вы делаете резервную копию, max_allowed_packet игнорируется mysqldump (дизайн?) Фактическое дополнение - 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