Soy extremadamente nuevo en MySQL y lo estoy ejecutando en Windows. Estoy tratando de restaurar una base de datos desde un archivo de volcado en MySQL, pero aparece el siguiente error:

$ >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'.

Lo intenté $ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sqlpero esto me dio lo siguiente: ERROR at line 1: Unknown command '\☻'. es un archivo de volcado de 500 Mb, y cuando veo su contenido usando gVIM, todo lo que puedo ver son expresiones y datos que no son comprensibles. Además, cuando trato de copiar el contenido del archivo para publicar aquí, todo lo que puedo copiar es: SQLite format 3esto parece extraño.

La referencia a --binary-mode(introducida en MySQL 5.6.3) es probablemente una distracción.

No parece que esté tratando con un archivo de salida mysqldump, allí. Prueba la fileutilidad.

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

Si no obtiene la ASCII textrespuesta, está lidiando con algo que no es un archivo de volcado mysqldumpo con algo que ha sido comprimido (con gzip o bzip2, por ejemplo), que usted ' Necesitaría descomprimir antes de conectarlo mysql.

Si ve, SQLite 3.x databaseentonces definitivamente tiene su respuesta ... es una base de datos SQLite sin formato, no un archivo de volcado de MySQL.

De hecho, los primeros bytes de una base de datos SQLite son estos:

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

Tenga en cuenta que el 16to octeto aquí es 0x00, explicando el ERROR: ASCII '\0' appeared in the statement...mensaje en este caso. La sugerencia --binary-modeapropiada es una falsa alarma.

Usuarios de Windows: la utilidad 'archivo' es una herramienta de Unix, pero la versión de Windows se puede encontrar aquí .

Ventanas

Crea tus archivos de volcado con este comando

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

Utilizando:

.\mysqldumb --help

-r, --result-file = nombre

                 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.

Tuve este error una vez, después de ejecutar mysqldumpen Windows PowerShell así:

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

Lo que hice fue cambiarlo a esto (canalizar a 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

¡Y el problema se fue!

Yo también en PowerShell

Encontré este problema cuando estaba usando PowerShell para llamar a mysqldump y > para canalizar la salida al archivo. PowerShell estaba usando una codificación incorrecta al crear el archivo y se me presentó el mismo error cuando intenté importar el archivo usando mysql .. <exported-file.sql

Descubrí que establecer la codificación predeterminada en UTF8 en la sesión de PowerShell resolvió este problema.

Mi resolución - Probado PowerShell 5.1:

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

Ejemplo: cómo estaba produciendo la exportación (simplificado) :

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

Nota: Descubierto que esto no funciona en PowerShell 4.0

Mi entorno de desarrollo ejecutaba 5.1, pero prod está en 4.0 y mi solución inicial no funciona en versiones anteriores de PowerShell.

Necesitará usar | Set-Content -Encoding UTF8 $fileName

Esto ya fue sugerido por Ifedi

¿Has intentado abrir en Notepad ++ (u otro editor) y convertirnos / guardarnos en UTF-8?

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

Otra opción puede ser usar textwrangle para abrir y guardar el archivo como UTF-8: http://www.barebones.com/products/textwrangler/

Alguien me envió un gtar comprimido. Ni siquiera estaba familiarizado con gtar, pero es otro formato de compresión.

$ 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

Sin embargo, pude descomprimirlo igual que de costumbre:

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

Y luego podría hacer la importación:

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

Solución: extraiga el archivo de copia de seguridad y luego restaure este volcado sql extraído.

Ejemplo:

La copia de seguridad se ha tomado como un archivo dump.sql.gz y se extrae usando cmd gunzip de la siguiente manera,

shell>  gunzip dump.sql.gz

Y RESTORE extrajo el archivo dump.sql.

Ref: Acerca del modo binario e interactivo de MySQL.

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

¡Funciona para mí y todo listo!

En mi caso, el archivo estaba dañado. La base de datos estaba comprimida con extensión, .bz2pero en realidad era una .tar.bz2.

Descomprimir usando bzip2 -dkno genera ningún error y genera el archivo. Usar el comando fileen las salidas del archivo bzip2 compressed data, block size = 900kpara que ni siquiera se vea mal usarlo.

Tuve que usar tar -xf myfile.bz2