Erro ao importar arquivo de despejo grande do MySQL, que inclui BLOBs binários no Windows

Estou tentando importar um arquivo de despejo do MySQL, que recebi da minha empresa de hospedagem, para minha máquina de desenvolvimento do Windows e estou tendo problemas.

Estou importando isso da linha de comando e estou recebendo um erro muito estranho:

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

Estou anexando a captura de tela porque estou assumindo que os dados binários serão perdidos ...

Não sei exatamente qual é o problema, mas dois possíveis problemas são o tamanho do arquivo (2 Gb) que não é incrivelmente grande, mas também não é trivialmente pequeno, e o outro é o fato de muitas dessas tabelas terem Imagens JPG nelas (e é por isso que o arquivo tem 2 GB de tamanho, na maior parte).
Além disso, o despejo foi feito em uma máquina Linux e estou importando isso para o Windows, não tenho certeza se isso pode aumentar os problemas (entendo que não deveria)

Agora, esse lixo binário é o motivo pelo qual acho que as imagens no arquivo podem ser um problema, mas pude importar despejos semelhantes da mesma empresa de hospedagem no passado, então não tenho certeza do que possa ser o problema.

Além disso, tentar examinar esse arquivo (e a linha 3118 em particular) é meio impossível, dado o seu tamanho (não sou muito útil com ferramentas de linha de comando do Linux, como grep, sed, etc.).

O arquivo pode estar corrompido, mas não sei exatamente como verificá-lo. O que eu baixei foi um arquivo .gz, que eu "testei" com o WinRar e ele diz que parece bom (estou assumindo que o gz tem algum tipo de CRC). Se você puder pensar em uma maneira melhor de testá-lo, eu adoraria tentar isso.

Alguma idéia do que poderia estar acontecendo / como superar esse erro?

Eu não sou muito apegado aos dados em particular, já que eu apenas quero isso como uma cópia para o desenvolvedor, por isso, se eu tiver que perder alguns registros, eu estou bem com isso, desde que o esquema permaneça perfeitamente correto.

Obrigado!
Daniel

Por esse motivo, eu sempre uso mysqldump --hex-blob.

Despejar novamente o banco de dados que codifica os blobs usando essa opção e ele funcionará.

Você pode tentar importá-lo usando um IDE do cliente mysql do Windows, como o sqlyog ou o administrador do mysql. Funcionou para mim uma vez.

Você não precisa necessariamente usar a opção --hex-blob. Acabei de resolver esse problema sozinho e o problema era que eu precisava que o --max_allowed_packet fosse definido com um valor suficientemente grande para acomodar o maior blob de dados que eu estaria carregando. Seu comando de restauração deve se parecer com:

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

Se você usar a opção --hex-blob, aumentará significativamente o tamanho do seu backup - por um fator de 2 ou mais. NOTA: para restaurar os mesmos dados que eu restaurei com o comando acima, é necessário definir o --max_allowed_packet = 64M em my.ini (cnf) e reiniciar o servidor, bem como configurá-lo para 64M na linha de comando para restaurar um dump criado com a opção --hex-blob.

Ainda pode haver um problema devido ao tamanho do arquivo grande, portanto, certifique-se de definir o pacote de permissão máxima para algum valor alto (parâmetro para o comando mysql).

Ok, eu tive esse problema hoje. Mas o meu problema era que o banco de dados já havia caído quando percebi que o backup estava quebrado. Então, não --hex-blobpara mim! Para poder consertar, fiz um pequeno script em PHP que converte a "string binária" na representação hexadecimal onde os valores são representados como "_binary '!@{#!@{#'"...

Ele está usando um REGEX para analisar o SQL, o que não é totalmente seguro, mas fez o trabalho para mim.

<?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 isso salve a alguém a dor de cabeça que tive!

Eu tenho um problema semelhante ao restaurar um arquivo de despejo do servidor Linux que contém dados binários. Os erros são algo comoERROR 1064 (42000) at line 551: You have an error in your SQL syntax;

Esse arquivo de despejo pode ser importado com êxito para o servidor Linux, mas não para o Windows.

Eu tentei com --hex-blobopção --max_allowed_packetee até mesmo transferir dados com pipeline em vez de arquivo .sql, mas sem sorte.

Finalmente resolvi isso usando o MySQL Workbench, e o comando gerado é 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"

Então eu tentei com a --default-character-set=utf8partir da linha de comando e funcionou. Espero que isso ajude alguém.