Sono estremamente nuovo in MySQL e lo eseguo su Windows. Sto cercando di ripristinare un database da un file di dump in MySQL, ma ottengo il seguente errore:

$ >mysql -u root -p -h localhost -D database -o < dump.sql
ERROR: ASCII '\0' appeared in the statement, but this is not allowed unless option --binary-mode is enabled and mysql is run in non-interactive mode. Set --binary-mode to 1 if ASCII '\0' is expected. Query: 'SQLite format 3'.

Ho provato $ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sqlma questo mi ha dato quanto segue ERROR at line 1: Unknown command '\☻'. È un file di dump di 500 Mb e quando visualizzo il suo contenuto usando gVIM, tutto ciò che posso vedere sono espressioni e dati che non sono comprensibili. Anche quando provo a copiare il contenuto dal file per pubblicare qui tutto ciò che posso copiare è: SQLite format 3questo tipo di sembra strano.

Il riferimento a --binary-mode(introdotto in MySQL 5.6.3) è probabilmente una distrazione.

Non sembra che tu abbia a che fare con un file di output mysqldump, lì. Prova l' fileutilità.

shell> file dumpfile.sql
dumpfile.sql: ASCII text

Se non ricevi la ASCII textrisposta, hai a che fare con qualcosa che non è affatto un file di dump mysqldumpo hai a che fare con qualcosa che è stato compresso (con gzip o bzip2, per esempio), che " d è necessario decomprimere prima di collegarlo mysql.

Se vedi, SQLite 3.x databaseallora hai sicuramente la tua risposta ... è un database SQLite non elaborato, non un file di dump MySQL.

Infatti, i primi pochi byte di un database SQLite sono questi:

53 51 4C 69 74 65 20 66  SQLite f
6F 72 6D 61 74 20 33 00  ormat 3^@

Si noti che il 16 ottetto qui è 0x00, spiegando il ERROR: ASCII '\0' appeared in the statement...messaggio in questo caso. Il suggerimento --binary-modeappropriato è un falso allarme.

Utenti Windows: l'utilità 'file' è uno strumento di Unix, ma la versione di Windows è disponibile qui .

finestre

Crea i tuoi file di dump con questo comando

.\mysqldump [dbname] -r [filename.sql]

usando:

.\mysqldumb --help

-r, --result-file = name

                 Direct output to a given file. This option should be used
                 in systems (e.g., DOS, Windows) that use carriage-return
                 linefeed pairs (\r\n) to separate text lines. This option
                 ensures that only a single newline is used.

Ho avuto questo errore una volta, dopo aver eseguito mysqldumpWindows PowerShell in questo modo:

mysqldump -u root p my_db --no-data --no-create-db --no-create-info --routines --triggers --skip-opt --set-gtid-purged=OFF > db_objects.sql

Quello che ho fatto è stato cambiarlo in questo (pipe invece in Set-Content):

mysqldump -u root p my_db --no-data --no-create-db --no-create-info --routines --triggers --skip-opt --set-gtid-purged=OFF | Set-Content db_objects.sql

E il problema è andato via!

Anche io in PowerShell

Ho riscontrato questo problema quando utilizzavo PowerShell per chiamare mysqldump e > per convogliare l'output in un file. PowerShell utilizzava una codifica errata durante la creazione del file e mi è stato presentato lo stesso errore quando ho provato a importare il file utilizzando mysql .. <exported-file.sql

Ho scoperto che l'impostazione della codifica predefinita su UTF8 nella sessione di PowerShell ha risolto questo problema.

La mia risoluzione - Testato PowerShell 5.1:

$PSDefaultParameterValues["Out-File:Encoding"] = "utf8";

Esempio: come stavo producendo l'esportazione (semplificata) :

$cmdExportDB = "mysqldump --host $Host --databases $DbName -u $UID =p$PWD > $fileName";
Invoke-Expression "& $cmdExportDB";

Nota: scoperto che questo non funziona su PowerShell 4.0

Il mio ambiente di sviluppo era in esecuzione 5.1, ma prod è a 4.0 e la mia correzione iniziale non funziona nelle versioni precedenti di PowerShell.

Bisogno di usare | Set-Content -Encoding UTF8 $fileName

Questo è già stato suggerito da Ifedi

Hai provato ad aprire in notepad ++ (o in un altro editor) e a convertirci / salvarci in UTF-8?

Vedi: /programming/7256049/notepad-converting-ansi-encoded-file-to-utf-8

Un'altra opzione potrebbe essere quella di utilizzare textwrangle per aprire e salvare il file come UTF-8: http://www.barebones.com/products/textwrangler/

Qualcuno mi ha mandato un gtar compresso. Non avevo nemmeno familiarità con gtar, ma è un altro formato di compressione.

$ file core_production-1432173533.sql.gtar
core_production-1432173533.sql.gtar: gzip compressed data, from Unix, last modified: Wed May 20 21:59:31 2015

Tuttavia, sono stato in grado di decomprimerlo come al solito:

tar -zxvf core_production-1432173533.sql.gtar
$ file core_production-1432173533.sql
core_production-1432173533.sql: ASCII text, with very long lines

E poi potrei fare l'importazione:

mysql -u root -p -h localhost core_production < core_production-1432173533.sql

Soluzione: estrarre il file di backup e quindi ripristinare questo dump sql estratto.

Esempio :

Il backup è stato preso come file dump.sql.gz ed estrailo usando gunzip cmd come segue,

shell>  gunzip dump.sql.gz

E RESTORE ha estratto il file dump.sql.

Rif: Informazioni sulla modalità binaria e interattiva di MySQL.

http://dev.mysql.com/doc/refman/5.7/en/mysql-command-options.html#option_mysql_binary-mode

Funziona per me e per il set !!

Nel mio caso, il file è stato danneggiato. Il database è stato compresso con estensione .bz2ma in realtà era un .tar.bz2.

Decomprossing utilizzando bzip2 -dknon genera alcun errore e genera il file. Utilizzando il comando filesull'output del file in bzip2 compressed data, block size = 900kmodo che non sembri nemmeno sbagliato usarlo.

Ho dovuto usare tar -xf myfile.bz2