Eu sou extremamente novo no MySQL e estou executando no Windows. Estou tentando restaurar um banco de dados de um arquivo de despejo no MySQL, mas recebo o seguinte erro:

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

Eu tentei, $ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sqlmas isso me deu o seguinte ERROR at line 1: Unknown command '\☻'. É um arquivo de despejo de 500 Mb e, quando visualizo seu conteúdo usando o gVIM, tudo o que vejo são expressões e dados que não são compreensíveis. Além disso, quando tento copiar o conteúdo do arquivo para postar aqui, tudo o que posso copiar é: SQLite format 3Isso parece estranho.

A referência a --binary-mode(introduzida no MySQL 5.6.3) é provavelmente uma distração.

Não parece que você está lidando com um arquivo de saída do mysqldump. Experimente o fileutilitário.

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

Se você não obtiver a ASCII textresposta, estará lidando com algo que não é um arquivo de despejo mysqldumpou com algo que foi compactado (com gzip ou bzip2, por exemplo), que você ' d precisa descompactar antes de inseri-lo mysql.

Se você vê SQLite 3.x database, definitivamente tem sua resposta ... é um banco de dados SQLite bruto, não um arquivo de despejo do MySQL.

De fato, os primeiros bytes de um banco de dados SQLite são estes:

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

Observe que o 16º octeto aqui é 0x00, explicando a ERROR: ASCII '\0' appeared in the statement...mensagem neste caso. A sugestão --binary-modeapropriada é um alarme falso.

Usuários do Windows: o utilitário 'file' é uma ferramenta do Unix, mas a versão do Windows pode ser encontrada aqui .

janelas

Crie seus arquivos de despejo com este 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.

Eu tive esse erro uma vez, depois de executar mysqldumpno Windows PowerShell da seguinte maneira:

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

O que fiz foi alterá-lo para este (canal em vez 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

E o problema foi embora!

Eu também no PowerShell

Encontrei esse problema quando estava usando o PowerShell para chamar o mysqldump e > canalizar a saída para o arquivo. O PowerShell estava usando a codificação incorreta ao criar o arquivo e recebi o mesmo erro ao tentar importar o arquivo usando o mysql .. <exported-file.sql

Eu descobri que a configuração da codificação padrão como UTF8 na sessão do PowerShell resolveu esse problema.

Minha resolução - Testado PowerShell 5.1:

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

Exemplo: como eu estava produzindo a exportação (simplificada) :

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

Nota: Descoberto isso não funciona no PowerShell 4.0

Meu ambiente de desenvolvimento estava executando o 5.1, mas o prod está em 4.0 e minha correção inicial não funciona nas versões mais antigas do PowerShell.

Precisa usar | Set-Content -Encoding UTF8 $fileName

Isso já foi sugerido por Ifedi

Você já tentou abrir no notepad ++ (ou outro editor) e nos converter / salvar em UTF-8?

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

Outra opção pode ser usar textwrangle para abrir e salvar o arquivo como UTF-8: http://www.barebones.com/products/textwrangler/

Alguém me enviou um gtar comprimido. Não conhecia muito o gtar, mas é outro formato de compactação.

$ 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

No entanto, consegui descompactá-lo da mesma maneira que de costume:

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

E então eu poderia fazer a importação:

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

Solução: extraia o arquivo de backup e, em seguida, restaure esse despejo sql extraído.

Exemplo:

O backup foi obtido como arquivo dump.sql.gz e extraído usando o gunzip cmd da seguinte maneira:

shell>  gunzip dump.sql.gz

E RESTORE extraiu o arquivo dump.sql.

Ref: Sobre o modo binário e interativo do MySQL.

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

Funciona para mim e tudo pronto!

No meu caso, o arquivo foi corrompido. O banco de dados foi compactado com extensão, .bz2mas na verdade era um .tar.bz2.

Descomprovar usando bzip2 -dknão gera nenhum erro e gera o arquivo. Usar o comando filenas saídas do arquivo bzip2 compressed data, block size = 900kpara que nem pareça errado usá-lo.

Eu tive que usar tar -xf myfile.bz2