Errore durante l'importazione di file di dump MySQL di grandi dimensioni che include BLOB binari in Windows

Sto cercando di importare un file di dump MySQL, che ho ottenuto dalla mia società di hosting, nella mia macchina di sviluppo di Windows, e sto riscontrando problemi.

Sto importando questo dalla riga di comando e sto ricevendo un errore molto strano:

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

Allego lo screenshot perché suppongo che i dati binari andranno persi ...

Non sono esattamente sicuro di quale sia il problema, ma due potenziali problemi sono le dimensioni del file (2 GB) che non è follemente grande, ma non è nemmeno banalmente piccolo, e l'altro è il fatto che molte di queste tabelle hanno Immagini JPG al loro interno (motivo per cui il file ha una dimensione di 2 GB, per la maggior parte).
Inoltre, il dump è stato preso in una macchina Linux e lo sto importando in Windows, non sono sicuro che ciò possa aggiungere problemi (capisco che non dovrebbe)

Ora, quella spazzatura binaria è il motivo per cui penso che le immagini nel file potrebbero essere un problema, ma in passato sono stato in grado di importare dump simili dalla stessa società di hosting, quindi non sono sicuro di quale potrebbe essere il problema.

Inoltre, cercare di esaminare questo file (e la riga 3118 in particolare) è un po 'impossibile date le sue dimensioni (non sono molto utile con gli strumenti della riga di comando di Linux come grep, sed, ecc.).

Il file potrebbe essere danneggiato, ma non sono sicuro di come controllarlo. Quello che ho scaricato era un file .gz, che ho "testato" con WinRar e mi dice che sembra OK (suppongo che gz abbia un qualche tipo di CRC). Se riesci a pensare a un modo migliore per testarlo, mi piacerebbe provarlo.

Qualche idea su cosa potrebbe succedere / come superare questo errore?

In particolare non sono molto legato ai dati, dal momento che voglio solo questo come una copia per dev, quindi se devo perdere qualche record, sto bene con quello, purché lo schema rimanga perfettamente valido.

Grazie!
Daniel

Per questo motivo lo uso sempre mysqldump --hex-blob.

Eseguire nuovamente il dump del database che codifica i BLOB utilizzando questa opzione e funzionerà.

Puoi provare a importarlo usando un IDE client mysql di Windows come sqlyog o amministratore mysql. Ha funzionato per me una volta.

Non è necessario necessariamente utilizzare l'opzione --hex-blob. Ho appena risolto questo problema da solo e il problema era che avevo bisogno che --max_allowed_packet fosse impostato su un valore abbastanza grande da contenere il BLOB di dati più grande che avrei caricato. Il comando di ripristino dovrebbe assomigliare a:

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

Se usi l'opzione --hex-blob aumenterai in modo significativo la dimensione del tuo backup - di un fattore 2 o più. NOTA: per ripristinare gli stessi dati che ho ripristinato con il comando sopra richiesto, è necessario impostare --max_allowed_packet = 64M in my.ini (cnf) e riavviare il server POI COME impostarlo su 64M sulla riga comandi per ripristinare un dump creato con l'opzione --hex-blob.

Potrebbe esserci ancora un problema a causa delle dimensioni del file di grandi dimensioni, quindi assicurati di impostare il valore massimo consentito su pacchetto (parametro per il comando mysql).

Ok, ho avuto questo problema oggi. Ma il mio problema era che il database era già caduto quando mi sono reso conto che il backup era rotto. Quindi no --hex-blobper me! Per poterlo risolvere ho creato un piccolo script in PHP che converte la "stringa binaria" nella rappresentazione esadecimale in cui i valori sono rappresentati come "_binary '!@{#!@{#'"...

Sta usando un REGEX per analizzare l'SQL, che non è completamente sicuro, ma ha fatto il lavoro per me.

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

Spero che salvi qualcuno il mal di testa che ho avuto!

Ho un problema simile quando ripristino un file di dump dal server Linux che contiene dati binari. Gli errori sono qualcosa del genereERROR 1064 (42000) at line 551: You have an error in your SQL syntax;

Questo file di dump può essere importato correttamente nel server Linux ma non in Windows.

Ho provato con l' --hex-blobopzione e --max_allowed_packetpersino il trasferimento di dati con pipeline anziché file .sql, ma senza fortuna.

Alla fine l'ho risolto utilizzando MySQL Workbench e il comando generato è simile

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"

Poi ho provato con --default-character-set=utf8dalla riga di comando e ha funzionato. Spero che questo possa aiutare qualcuno.