Ошибка импорта большого файла дампа 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, поэтому, если мне придется потерять несколько записей, у меня все в порядке, пока схема остается совершенно здоровой.

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

По этой причине я всегда использую 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командной строки, и это сработало. Надеюсь, это кому-нибудь поможет.