Восстановление дампа MySQL с бинарными блоками

Question

Я перемещаю базу данных MySQL с недоступного на данный момент сервера на новый. Дамп содержит таблицы, которые, в свою очередь, содержат двоичные капли, что, по-видимому, вызывает проблемы с клиентом командной строки MySQL. При попытке восстановить базу данных, я получаю следующее сообщение об ошибке:

ERROR at line 694: Unknown command '\''. 

Я осмотрел линию, на которой возникающая ошибку и обнаружил, что это огромная команда вставки, которая, кажется (около 900K символов.) вставьте бинарные капли в таблицу.

Теперь я нашел thesetwo вопросы, которые, кажется, связаны с моим. Однако оба ответа не помогли решить мою проблему. Добавление --default-character-set=utf8 или даже --default-caracter-set=latin1 ничего не изменило, и создание дампа с --hex-dump невозможно, так как исходный сервер баз данных больше не доступен.

Есть ли способ восстановить эту резервную копию через клиент командной строки MySQL? Если да, что мне нужно делать?

Пожалуйста, дайте мне знать, если вам нужна дополнительная информация.

Заранее спасибо.

EDIT: Я использую MySQL 5.6.35. Кроме того, в дополнение к описанным выше попыткам я уже пытался увеличить системную переменную max_allowed_packet до ее максимального значения - как на сервере, так и на клиенте - но безрезультатно.

Answer 1

Если я правильно помню, вам нужно установить max_allowed_packet в my.cnf на достаточно большое значение, чтобы разместить самый большой блок данных в файле дампа и перезапустить сервер MySQL.

Затем вы можете использовать команду восстановления, как это:

mysql --max_allowed_packet=64M < your_dumpfile.sql 

Подробнее здесь: [https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_max_allowed_packet]

Answer 2

Нет решения, только подтверждение того, что я видел такое же поведение с «текст "тип поля, который содержит длинную строку JSON. Файл SQL (backup), который генерирует MySQLdump, имеет инструкцию INSERT и обрезает длину этого конкретного текстового поля «около» 64K (существует много экранированных кавычек/двойных кавычек и различных символов UTF-8) - без предупреждения что такое усечение произошло.

Естественно, восстановление в столбец JSON не удается из-за преждевременного завершения форматированной строки JSON.

В этом случае было нечетным, что столбец в резервной таблице был определен как ТЕКСТ, который действительно должен был быть ограничен 64 КБ. По подозрению, я изменил схему для резервного стола в MEDIUMTEXT. После THAT MySQLdump больше не усекал эту строку в инструкции INSERT где-то за пределами 64K.

Похоже, что MySQLdump не просто выводит весь столбец, но обрезает все, что он думает, что максимальная длина строки должна основываться на информации о схеме и НЕ выдает предупреждения при ее усечении.