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

Question

Я несколько лет создавал резервную копию базы данных 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 Server 2003 sp2

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

George

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

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

Answer 2

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

При создании резервной копии 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