Назад | Перейти на главную страницу

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

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

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

ОШИБКА 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). Если вы можете придумать лучший способ проверить это, я бы хотел попробовать это.

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

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

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

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

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

Вы можете попробовать импортировать его с помощью клиентской IDE Windows mysql, такой как sqlyog или mysql administrator. Однажды у меня это сработало.

Вам не обязательно использовать параметр --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) и перезапустить сервер ТАКЖЕ, КАК установить его на 64M в командной строке для восстановления дампа, созданного с помощью параметр --hex-blob.

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