Fehler beim Importieren einer großen MySQL-Dump-Datei, die binäre BLOBs in Windows enthält

Ich versuche, eine MySQL-Dump-Datei, die ich von meiner Hosting-Firma erhalten habe, in meinen Windows-Entwicklungscomputer zu importieren, und ich habe Probleme.

Ich importiere dies von der Kommandozeile und erhalte einen sehr seltsamen Fehler:

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

Ich hänge den Screenshot an, weil ich davon ausgehe, dass die Binärdaten verloren gehen ...

Ich bin mir nicht ganz sicher, wo das Problem liegt, aber zwei mögliche Probleme sind die Größe der Datei (2 GB), die nicht wahnsinnig groß ist, aber auch nicht trivial klein, und das andere ist die Tatsache, dass viele dieser Tabellen vorhanden sind JPG-Bilder in ihnen (weshalb die Datei zum größten Teil 2 GB groß ist).
Außerdem wurde der Speicherauszug auf einem Linux-Computer erstellt und ich importiere ihn in Windows. Ich bin mir nicht sicher, ob dies zu den Problemen beitragen könnte (ich verstehe, dass dies nicht der Fall sein sollte).

Dieser binäre Müll ist der Grund, warum ich denke, dass die Bilder in der Datei ein Problem sein könnten, aber ich konnte in der Vergangenheit ähnliche Dumps von derselben Hosting-Firma importieren, daher bin ich mir nicht sicher, was das Problem sein könnte.

Außerdem ist der Versuch, in diese Datei (und insbesondere in Zeile 3118) zu schauen, aufgrund ihrer Größe unmöglich (ich bin mit Linux-Befehlszeilentools wie grep, sed usw. nicht wirklich praktisch).

Die Datei ist möglicherweise beschädigt, aber ich bin nicht genau sicher, wie ich sie überprüfen soll. Was ich heruntergeladen habe, war eine .gz-Datei, die ich mit WinRar "getestet" habe und die besagt, dass sie in Ordnung aussieht (ich gehe davon aus, dass gz eine Art CRC hat). Wenn Sie sich einen besseren Weg zum Testen vorstellen können, würde ich das gerne ausprobieren.

Irgendwelche Ideen, was los sein könnte / wie man diesen Fehler überwinden kann?

Ich bin insbesondere nicht sehr an die Daten gebunden, da ich dies nur als Kopie für Entwickler haben möchte. Wenn ich also ein paar Datensätze verlieren muss, bin ich damit einverstanden, solange das Schema einwandfrei bleibt.

Vielen Dank!
Daniel

Aus diesem Grund benutze ich immer mysqldump --hex-blob.

Setzen Sie die Datenbank, die die Blobs codiert, mit diesem Schalter erneut ab, und es funktioniert.

Sie können versuchen, es mit einer Windows-MySQL-Client-IDE wie SQLlyog oder MySQL-Administrator zu importieren. Es hat einmal bei mir funktioniert.

Sie müssen nicht unbedingt die Option --hex-blob verwenden. Ich habe dieses Problem gerade selbst gelöst und das Problem war, dass das --max_allowed_packet auf einen Wert gesetzt werden musste, der groß genug ist, um den größten Daten-Blob aufzunehmen, den ich laden würde. Ihr Wiederherstellungsbefehl sollte ungefähr so ​​aussehen:

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

Wenn Sie die Option --hex-blob verwenden, erhöhen Sie die Größe Ihres Backups erheblich - um den Faktor 2 oder mehr. ANMERKUNG: Um dieselben Daten wiederherzustellen, die ich mit dem obigen Befehl wiederhergestellt habe, müssen Sie --max_allowed_packet = 64M in my.ini (cnf) setzen und den Server neu starten sowie ihn in der Befehlszeile auf 64M setzen, um einen mit erstellten Dump wiederherzustellen die Option --hex-blob.

Aufgrund der großen Dateigröße kann es immer noch zu Problemen kommen. Stellen Sie daher sicher, dass Sie das maximal zulässige Paket auf einen hohen Wert setzen (Parameter für den Befehl mysql).

Ok, ich hatte dieses Problem heute. Mein Problem war jedoch, dass die Datenbank bereits gelöscht wurde, als ich feststellte, dass die Sicherung fehlerhaft war. Also nein --hex-blobfür mich! Um das Problem beheben zu können, habe ich in PHP ein kleines Skript erstellt, das die "Binärzeichenfolge" in die Hex-Darstellung konvertiert, in der die Werte wie "_binary '!@{#!@{#'"...

Es wird ein REGEX zum Parsen von SQL verwendet, was nicht ganz sicher ist, aber es hat den Job für mich erledigt.

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

Ich hoffe, es erspart jemandem die Kopfschmerzen, die ich bekam!

Ich habe ein ähnliches Problem beim Wiederherstellen einer Dump-Datei vom Linux-Server, die Binärdaten enthält. Die Fehler sind so etwas wieERROR 1064 (42000) at line 551: You have an error in your SQL syntax;

Diese Dump-Datei konnte erfolgreich in den Linux-Server importiert werden, nicht jedoch in Windows.

Ich habe versucht, mit --hex-blobOption und --max_allowed_packetsogar Daten mit Pipeline anstelle von .sql-Datei zu übertragen, aber ohne Glück.

Ich habe dies schließlich mithilfe von MySQL Workbench gelöst, und der generierte Befehl ist wie folgt

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"

Dann habe ich es mit --default-character-set=utf8der Kommandozeile versucht und es hat funktioniert. Hoffe das wird jemandem helfen.