Erreur lors de l'importation d'un gros fichier de vidage MySQL qui comprend des BLOB binaires dans Windows

J'essaie d'importer un fichier de vidage MySQL, que j'ai obtenu de mon hébergeur, dans ma machine de développement Windows, et je rencontre des problèmes.

J'importe ceci depuis la ligne de commande, et je reçois une erreur très étrange:

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

Je joins la capture d'écran parce que je suppose que les données binaires seront perdues ...

Je ne sais pas exactement quel est le problème, mais deux problèmes potentiels sont la taille du fichier (2 Go) qui n'est pas incroyablement grande, mais elle n'est pas non plus très petite non plus, et l'autre est le fait que beaucoup de ces tableaux ont Images JPG en eux (c'est pourquoi le fichier est de 2 Go, pour la plupart).
En outre, le vidage a été effectué sur une machine Linux et je l'importe dans Windows, je ne sais pas si cela pourrait aggraver les problèmes (je comprends que cela ne devrait pas)

Maintenant, ces ordures binaires sont la raison pour laquelle je pense que les images dans le fichier peuvent être un problème, mais j'ai pu importer des vidages similaires de la même société d'hébergement dans le passé, donc je ne sais pas quel pourrait être le problème.

De plus, essayer de regarder dans ce fichier (et la ligne 3118 en particulier) est un peu impossible étant donné sa taille (je ne suis pas vraiment à portée de main avec les outils de ligne de commande Linux comme grep, sed, etc.).

Le fichier est peut- être corrompu, mais je ne sais pas exactement comment le vérifier. Ce que j'ai téléchargé était un fichier .gz, que j'ai "testé" avec WinRar et il dit qu'il semble OK (je suppose que gz a une sorte de CRC). Si vous pouvez penser à une meilleure façon de le tester, j'adorerais essayer.

Des idées sur ce qui pourrait se passer / comment surmonter cette erreur?

Je ne suis pas très attaché aux données en particulier, car je veux juste que ce soit une copie pour le dev, donc si je dois perdre quelques enregistrements, ça me convient, tant que le schéma reste parfaitement sain.

Merci!
Daniel

Pour cette raison, j'utilise toujours mysqldump --hex-blob.

Re-dump la base de données encodant les blobs à l'aide de ce commutateur et cela fonctionnera.

Vous pouvez essayer de l'importer en utilisant un IDE client mysql Windows comme sqlyog ou administrateur mysql. Cela a fonctionné pour moi une fois.

Vous n'avez pas nécessairement besoin d'utiliser l'option --hex-blob. Je viens de résoudre ce problème moi-même et le problème était que j'avais besoin que le paramètre --max_allowed_packet soit défini sur une valeur suffisamment grande pour accueillir le plus gros blob de données que je chargerais. Votre commande de restauration devrait ressembler à ceci:

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

Si vous utilisez l'option --hex-blob, vous augmenterez considérablement la taille de votre sauvegarde - d'un facteur 2 ou plus. REMARQUE: pour restaurer les mêmes données que celles que j'ai restaurées avec la commande ci-dessus, il fallait définir --max_allowed_packet = 64M dans my.ini (cnf) et redémarrer le serveur COMME BIEN en le définissant sur 64M sur la ligne de commande pour restaurer un vidage créé avec l'option --hex-blob.

Il pourrait toujours y avoir un problème en raison de la grande taille du fichier, alors assurez-vous de définir max-allowed-packet sur une valeur élevée (param pour la commande mysql).

Ok, j'ai eu ce problème aujourd'hui. Mais mon problème était que la base de données était déjà supprimée lorsque j'ai réalisé que la sauvegarde était interrompue. Alors non --hex-blobpour moi! Pour pouvoir y remédier j'ai fait un petit script en PHP qui convertit la "chaîne binaire" en représentation hexadécimale où les valeurs sont représentées comme "_binary '!@{#!@{#'"...

Il utilise un REGEX pour analyser le SQL, ce qui n'est pas complètement sûr, mais il a fait le travail pour moi.

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

J'espère que cela sauve quelqu'un le mal de tête que j'ai eu!

J'ai un problème similaire lors de la restauration d'un fichier de vidage à partir d'un serveur Linux qui contient des données binaires. Les erreurs sont quelque chose commeERROR 1064 (42000) at line 551: You have an error in your SQL syntax;

Ce fichier de vidage a pu être importé avec succès dans le serveur Linux mais pas dans Windows.

J'ai essayé avec --hex-bloboption et --max_allowed_packetet même transférer des données avec pipeline au lieu du fichier .sql, mais sans chance.

J'ai finalement résolu cela en utilisant MySQL Workbench, et la commande générée est comme

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"

Ensuite, j'ai essayé avec la --default-character-set=utf8ligne de commande et cela a fonctionné. J'espère que cela aidera quelqu'un.