Habilite el modo binario mientras restaura una base de datos desde un volcado SQL

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

Intenté poner --binary-modeel archivo ini pero todavía da el mismo error. ¿Qué tengo que hacer? Por favor ayuda.

ACTUALIZAR

Como sugirió Nick en su comentario, lo intenté $ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sqlpero 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.

Descomprima el archivo y luego vuelva a importar.

Encuentro el mismo problema en Windows al restaurar un archivo de volcado. Mi archivo de volcado fue creado con Windows powershell y mysqldump como:

mysqldump db > dump.sql

El problema proviene de que la codificación predeterminada de powershell es UTF16. Para profundizar en esto, podemos usar la utilidad "archivo" de GNU, y existe una versión para Windows aquí .
La salida de mi archivo de volcado es:

Texto Unicode UTF-16 Little-endian, con líneas muy largas, con terminadores de línea CRLF.

Entonces se necesita una conversión del sistema de codificación, y hay varios software que pueden hacer esto. Por ejemplo en emacs,

M-x set-buffer-file-coding-system

luego ingrese el sistema de codificación requerido como utf-8.

Y en el futuro, para un mejor resultado de mysqldump, use:

mysqldump <dbname> -r <filename>

y luego la salida se maneja por mysqldumpsí misma pero no la redirección de powershell.

referencia: /dba/44721/error- while - restoring-a - database - from - an - sql - dump

En una máquina con Windows, siga los pasos anteriores.

1. Abrir archivo en el bloc de notas.
2. Haga clic en Guardar como
3. Seleccione el tipo de codificación UTF-8.

Ahora obtenga su db.

Extraiga su archivo con la herramienta de archivo Tar. puedes usarlo de esta manera:

tar xf example.sql.gz

¿Ha intentado abrir en notepad ++ (u otro editor) y convertirnos / guardarnos a UTF-8?

Ver: notepad ++ conversión de archivo codificado ansi a utf-8

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

Tuve este error una vez, después de ejecutar mysqldumpWindows 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 (tubería en lugar de 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!

Puede ser que su dump.sql tenga un carácter basura al principio de su archivo o que haya una línea en blanco al principio.

Si no tienes suficiente espacio o no quieres perder tiempo descomprimiéndolo, prueba este comando.

gunzip < compressed-sqlfile.gz | mysql -u root -p

No olvide reemplazar compressed-sqlfile.gz con su nombre de archivo comprimido.

La restauración de .gz no funcionará sin el comando que proporcioné anteriormente.

Debe archivar el problema dump.sql. Utilice Sequel Pro para comprobar su archivo ecoding. Debe haber caracteres basura en su dump.sql.

Tuve el mismo problema, pero descubrí que el archivo de volcado era en realidad una copia de seguridad del servidor MSSQL, no MySQL.

A veces, los archivos de respaldo heredados nos juegan una mala pasada. Verifique su archivo de volcado.

En la ventana de la terminal:

~$ cat mybackup.dmp 

El resultado fue:

TAPE??G?"5,^}???Microsoft SQL ServerSPAD^LSFMB8..... etc...

Para dejar de procesar el comando cat:

CTRL + C

zcat /path/to/file.sql.gz | mysql -u 'root' -p your_database

El archivo que está intentando importar es un archivo zip. Descomprima el archivo y luego intente importarlo nuevamente.

En Linux Descomprima su archivo usando gunzip Edite su archivo SQL descomprimido usando

vi unzipsqlfile.sql

Elimine la primera línea binaria con esc dd vaya al final del archivo con esc shift g elimine la última línea binaria con dd guarde el archivo esc x: Luego vuelva a importar a mysql con:

mysql -u nombre de usuario -p new_database <unzipsqlfile.sql

Lo realicé con un archivo sql 20go de una copia de seguridad jetbackup cpanel mysql. Tenga paciencia para esperar que vi haga el trabajo para archivos grandes

Su archivo debe tener solo la extensión .sql, (.zip, .gz .rar), etc.no admitirá. ejemplo: dump.sql

Puede usar esto para corregir el error:

zcat {address_sql_database(.tar.gz)} | mysql -u root -p {database_name} --binary-mode

Sé que la pregunta sobre los carteles originales se resolvió, pero vine aquí a través de Google, y las diversas respuestas finalmente me llevaron a descubrir que mi SQL se descargó con un juego de caracteres predeterminado diferente al que se usó para importarlo. Recibí el mismo error que en la pregunta original, pero como nuestro volcado se canalizó a otro cliente MySQL, no pudimos seguir la ruta de abrirlo con otra herramienta y guardarlo de manera diferente.

Para nosotros, la solución resultó ser la --default-character-set=utf8mb4opción, para ser utilizada tanto en la llamada de mysqldumpcomo en la llamada para importarla vía mysql. Por supuesto, el valor del parámetro puede diferir para otros que enfrentan el mismo problema, solo es importante mantenerlo igual, ya que la configuración predeterminada de los servidores (o las herramientas) puede ser cualquier juego de caracteres.

¡Viejo pero dorado!

En MacOS (Catalina 10.15.7) fue un poco extraño: tuve que cambiar el nombre de mi dump.sqlen dump.zipy después de eso, tuve que usar el buscador (!) Para descomprimirlo. en terminal, unzip dump.zipodertar xfz dump.sql[or .gz .tar ...] conduce a mensajes de error.

Finalmente, Finder lo ha descomprimido totalmente bien, después de eso pude importar el archivo sin problemas.