Error al importar un gran archivo de volcado de MySQL que incluye BLOB binarios en Windows

Estoy tratando de importar un archivo de volcado MySQL, que obtuve de mi empresa de alojamiento, a mi máquina de desarrollo de Windows, y estoy teniendo problemas.

Estoy importando esto desde la línea de comandos, y obtengo un error muy extraño:

ERROR 2005 (HY000) en la línea 3118: host de servidor MySQL desconocido '╖? * Á ± dÆ╦N╪Æ · h ^ ye "π╩i╪ Z + - $ ▼ ₧ ╬Y.∞┌ | ↕╘l∞ / l ╞⌂î7æ▌X█XE.ºΓ [; ╦ï ♣ éµ♂º╜┤║] .♂┐φ9dë╟█'╕ÿG∟═0à¡úè ♦ ╥ ↑ ù ♣ ♦ ¥ '╔NÑ' (11004)

Adjunto la captura de pantalla porque supongo que los datos binarios se perderán ...

No estoy exactamente seguro de cuál es el problema, pero dos posibles problemas son el tamaño del archivo (2 Gb) que no es increíblemente grande, pero tampoco es trivialmente pequeño, y el otro es el hecho de que muchas de estas tablas tienen Imágenes JPG en ellas (es por eso que el archivo tiene un tamaño de 2 Gb, en su mayor parte).
Además, el volcado se realizó en una máquina Linux y estoy importando esto a Windows, no estoy seguro de si eso podría aumentar los problemas (entiendo que no debería)

Ahora, esa basura binaria es la razón por la que creo que las imágenes en el archivo podrían ser un problema, pero he podido importar volcados similares de la misma empresa de alojamiento en el pasado, así que no estoy seguro de cuál podría ser el problema.

Además, tratar de examinar este archivo (y la línea 3118 en particular) es algo imposible dado su tamaño (no soy realmente útil con herramientas de línea de comandos de Linux como grep, sed, etc.).

El archivo puede estar dañado, pero no estoy exactamente seguro de cómo verificarlo. Lo que descargué fue un archivo .gz, que "probé" con WinRar y dice que se ve bien (supongo que gz tiene algún tipo de CRC). Si puedes pensar en una mejor manera de probarlo, me encantaría intentarlo.

¿Alguna idea de lo que podría estar pasando / cómo superar este error?

No estoy muy apegado a los datos en particular, ya que solo quiero esto como una copia para el desarrollador, así que si tengo que perder algunos registros, estoy bien con eso, siempre y cuando el esquema permanezca perfectamente sólido.

¡Gracias!
Daniel

Por esta razón siempre uso mysqldump --hex-blob.

Vuelva a volcar la base de datos que codifica los blobs con este modificador y funcionará.

Puede intentar importarlo utilizando un IDE de cliente de mysql de windows como sqlyog o mysql administrador. A mí me funcionó una vez.

No necesariamente necesita usar la opción --hex-blob. Acabo de resolver este problema por mi cuenta y el problema era que necesitaba que --max_allowed_packet se configurara en un valor lo suficientemente grande como para acomodar el blob de datos más grande que estaría cargando. Su comando de restauración debería ser similar a:

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

Si usa la opción --hex-blob, aumentará significativamente el tamaño de su copia de seguridad - en un factor de 2 o más. NOTA: para restaurar los mismos datos que restauré con el comando anterior, tuve que configurar --max_allowed_packet = 64M en my.ini (cnf) y reiniciar el servidor TAMBIÉN COMO configurarlo en 64M en la línea de comando para restaurar un volcado creado con la opción --hex-blob.

Todavía podría haber un problema debido al gran tamaño del archivo, así que asegúrese de establecer max-allow-packet en algún valor alto (param para el comando mysql).

Ok, tuve este problema hoy. Pero mi problema era que la base de datos ya se había caído cuando me di cuenta de que la copia de seguridad estaba rota. ¡Entonces no --hex-blobpara mí! Para poder solucionarlo, hice un pequeño script en PHP que convierte la "cadena binaria" en la representación hexadecimal donde los valores se representan como "_binary '!@{#!@{#'"...

Está utilizando un REGEX para analizar el SQL, que no es completamente seguro, pero hizo el trabajo por mí.

<?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) ;

¡Espero que le ahorre a alguien el dolor de cabeza que tengo!

Tengo un problema similar al restaurar un archivo de volcado del servidor Linux que contiene datos binarios. Los errores son algo comoERROR 1064 (42000) at line 551: You have an error in your SQL syntax;

Este archivo de volcado podría importarse con éxito al servidor Linux pero no a Windows.

He intentado con la --hex-blobopción e --max_allowed_packetincluso transfiriendo datos con pipeline en lugar del archivo .sql, pero sin suerte.

Finalmente resolví esto usando MySQL Workbench, y el comando generado es como

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"

Luego intenté con la --default-character-set=utf8línea de comando y funcionó. Espero que esto ayude a alguien.