Ошибка импорта большого файла дампа MySQL, который включает двоичные BLOB-файлы в Windows

Я пытаюсь импортировать файл дампа MySQL, полученный от моей хостинговой компании, на мой компьютер с Windows, и у меня возникают проблемы.

Я импортирую это из командной строки и получаю очень странную ошибку:

ОШИБКА 2005 (HY000) в строке 3118: Неизвестный хост сервера MySQL '╖?* ±dÆ╦N╪Æ·h^ye"π╩i╪ Z+-$▼₧╬Y.∞┌|↕╘l∞/l Æ▌î7æ▌X█XE.ºΓ[;╦ï♣éµ♂º╜┤║].♂┐φ9dë╟█'╕ÿG∟ =0à¡úè♦╥↑ù♣♦¥'╔NÑ' (11004)

альтернативный текст

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

Я не совсем уверен, в чем проблема, но две потенциальные проблемы - это размер файла (2 Гб), который не очень большой, но и не слишком мал, а другой - тот факт, что многие из этих таблиц имеют JPG изображения в них (именно поэтому размер файла составляет 2 ГБ, по большей части).
Кроме того, дамп был сделан на машине Linux, и я импортирую это в Windows, не уверен, что это может добавить к проблемам (я понимаю, что это не должно)

Именно из-за этого бинарного мусора я думаю, что изображения в файле могут быть проблемой, но в прошлом я мог импортировать подобные дампы из одной и той же хостинговой компании, поэтому я не уверен, в чем может быть проблема.

Кроме того, попытка заглянуть в этот файл (и в частности строку 3118) невозможна, учитывая его размер (я не очень удобен для таких инструментов командной строки Linux, как grep, sed и т. Д.).

Файл может быть поврежден, но я не совсем уверен, как это проверить. Я скачал файл.gz, который я "протестировал" с WinRar, и он говорит, что выглядит нормально (я предполагаю, что у gz есть какой-то CRC). Если вы можете придумать лучший способ проверить это, я хотел бы попробовать это.

Есть идеи, что может происходить / как обойти эту ошибку?

В частности, я не очень привязан к данным, так как я просто хочу, чтобы это было копией для dev, поэтому, если мне придется потерять несколько записей, у меня все в порядке, если схема остается совершенно здоровой.

Спасибо!
Даниил

Источник

5 ответов

Решение

По этой причине я всегда использую mysqldump --hex-blob,

Повторно сбросьте базу данных, кодирующую BLOB-объекты, используя этот переключатель, и он будет работать.

Вы можете попробовать импортировать его, используя IDE клиента Windows MySQL, например, sqlyog или mysql. Это сработало для меня один раз.

Источник

Вам не обязательно использовать параметр --hex-blob. Я только что решил эту проблему сам, и проблема заключалась в том, что мне нужно, чтобы --max_allowed_packet был установлен на достаточно большое значение, чтобы вместить самый большой двоичный объект данных, который я буду загружать. Ваша команда восстановления должна выглядеть примерно так:

mysql -u user -h hostname --max_allowed_packet=32M dbname < dumpfile.sql

Если вы используете опцию --hex-blob, вы значительно увеличите размер вашей резервной копии - в 2 раза или более. ПРИМЕЧАНИЕ: чтобы восстановить те же данные, которые я восстановил с помощью вышеуказанной команды, необходимо установить --max_allowed_packet=64M в my.ini(cnf) и перезапустить сервер AS WELL AS, установив его в 64M в командной строке для восстановления дампа, созданного с помощью опция --hex-blob.

Источник

Все еще может быть проблема из-за большого размера файла, поэтому убедитесь, что вы установили для max-allow-packet какое-то высокое значение (параметр для команды mysql).

Источник

Хорошо, у меня была эта проблема сегодня. Но моя проблема заключалась в том, что база данных уже была удалена, когда я понял, что резервная копия была повреждена. Так что нет --hex-blob для меня! Чтобы исправить это, я сделал небольшой скрипт на PHP, который преобразует "двоичную строку" в шестнадцатеричное представление, где значения представлены как "_binary '!@{#!@{#'"...

Он использует REGEX для синтаксического анализа SQL, что не совсем безопасно, но он сделал свою работу для меня.

<?php
function convertEncoding($str)
{
    $r = '';
    for ($i = 0; $i < mb_strlen($str); $i++) {
        $r .= sprintf('%02X', mb_ord(mb_substr($str, $i, 1, 'UTF-8'), 'UTF-8'));
    }

    return '0x' . $r;
}


$str = file_get_contents('data.sql');

$newStr = preg_replace_callback('/_binary \'(.+?)\'(,|\))/im', function ($str) {
    $s = convertEncoding(stripcslashes($str[1]));
    echo 'Translated: ' . $str[1] . ' => ' . $s . PHP_EOL;
    echo 'Ending char was: ' . $str[2] . PHP_EOL;
    return $s . $str[2];
}, $str);

file_put_contents('fixed.sql', $newStr) ;

Я надеюсь, что это спасет кого-то от головной боли!

Источник

У меня похожая проблема при восстановлении файла дампа с сервера Linux, который содержит двоичные данные. Ошибки что-то вроде ERROR 1064 (42000) at line 551: You have an error in your SQL syntax;

Этот файл дампа может быть успешно импортирован на сервер Linux, но не в Windows.

Я пробовал с --hex-blob вариант и --max_allowed_packet и даже передача данных с конвейером вместо файла.sql, но безуспешно.

Я наконец решил это с помощью MySQL Workbench, и сгенерированная команда

Running: mysql.exe --defaults-file="c:\users\admini~1\appdata\local\temp\tmp1fzxkx.cnf"  --protocol=tcp --host=localhost --user=root --port=3306 --default-character-set=utf8 --comments --database=platform  < "E:\\direcotory\\dump.sql"

Тогда я попробовал с --default-character-set=utf8 из командной строки, и это сработало. Надеюсь, это кому-нибудь поможет.

Источник
Другие вопросы по тегам