Habilite o modo binário ao restaurar um banco de dados de um dump SQL


99

Sou extremamente novo no MySQL e estou executando-o no Windows. Estou tentando restaurar um banco de dados de um dumpfile 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 colocar --binary-modeno arquivo ini, mas ainda dá o mesmo erro. O que devo fazer? Por favor ajude.

ATUALIZAR

Como sugerido por Nick em seu comentário, eu tentei, $ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sqlmas ele me deu o seguinte: ERROR at line 1: Unknown command '\☻'. É um arquivo de despejo de 500 Mb, e quando vejo seu conteúdo usando o gVIM, tudo que posso ver são expressões e dados que não são compreensíveis.


mysql -u root -p -h localhost -D database --binary-mode -o <dump.sql
Nick

Isso dá ERROR na linha 1: Comando desconhecido '\ ☻'.
user1434997

Eu estava recebendo este erro, mas obtive um novo dump do MySQL e tentei reimportar e funcionou bem. Nosso dump do MySQL vem em duas partes compactadas que devem ser concatenadas e depois descompactadas. Acho que a descompactação inicial foi interrompida, resultando em um .sqlarquivo com caracteres e codificações estranhas. A segunda tentativa funcionou bem.
Joshua Pinter

Respostas:


227

Descompacte o arquivo e importe-o novamente.


2
Você quer dizer compactar e descompactar?
J86 de

13
Funcionou assim para mim, descompacte o db.sql.gz, você obterá db.sql, renomeie-o novamente para db.sql.gz, não compacte-o, apenas renomeie-o e descompacte novamente para db.sql e agora você obterá o arquivo certo para importar.
MotsManish

@MotsManish Sério? Achei que fosse uma piada. Vou tentar e ver se funciona.
Joshua Pinter

Isso funcionou quando eu comprimi um arquivo para .tar.bz2usar o Linux e usei o WinRAR para extraí-lo no Windows. Eu não entendo . Agradável.
Shafiq al-Shaar

3
face palm
Rambatino

59

Eu encontro o mesmo problema no Windows ao restaurar um arquivo de despejo. Meu arquivo de despejo foi criado com windows powershell e mysqldump como:

mysqldump db > dump.sql

O problema vem da codificação padrão do PowerShell é UTF16. Para ver isso mais a fundo, podemos usar o utilitário "arquivo" do GNU, e existe uma versão do Windows aqui .
A saída do meu arquivo de despejo é:

Texto Unicode UTF-16 Little-endian, com linhas muito longas, com terminadores de linha CRLF.

Em seguida, é necessária uma conversão do sistema de codificação e existem vários softwares que podem fazer isso. Por exemplo no emacs,

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

em seguida, insira o sistema de codificação necessário, como utf-8.

E no futuro, para um melhor resultado do mysqldump, use:

mysqldump <dbname> -r <filename>

e então a saída é tratada por mysqldumpsi mesma, mas não o redirecionamento do PowerShell.

referência: /dba/44721/error-while-restoring-a-database-from-an-sql-dump


mysqldump <dbname> -r <filename> qualquer pessoa usando sistemas Windows ou DOS esta é a solução. A conversão de arquivos UTF-8 é uma distração. Use a opção -r, que direciona a saída para o nome do arquivo e manipula a alimentação de linha de retorno de carro CRLF (\ r \ n) que o Windows coloca nos arquivos, é aqui que está o problema. Obrigado pela excelente solução!
Timothy LJ Stewart

4
Em uma nota prática, resolvi isso depois de criar o arquivo no Powershell, convertendo o arquivo gerado em UTF-8 usando o Notepad ++.
Peter Majeed

Essa resposta, se eu não tivesse me aprofundado, teria me poupado horas de busca pela resposta correta. Gostaria de poder votar positivamente mais de uma vez.
sam452

Fiz o mesmo que @PeterMajeed. Uma rápida conversão e salvamento com o NotePad ++ me permitiu restaurar um arquivo existente
Stephen R,

20

Na máquina Windows, siga as etapas anteriores.

  1. Abra o arquivo no bloco de notas.
  2. Clique em Salvar como
  3. Selecione o tipo de codificação UTF-8.

Agora fonte seu banco de dados.


Isso funcionou para mim para um arquivo de backup SQL que foi criado executando o mysqldump via Powershell. A saída do Poweshell foi UTF-16. Mudar para UTF-8 resolveu o problema e me permitiu restaurar minha desmontagem do arquivo de backup.
Harry Mantheakis

9

Extraia seu arquivo com a ferramenta de arquivamento Tar. você pode usá-lo desta forma:

tar xf example.sql.gz

1
Esta foi a resposta para mim. No início, eu fiz um gunzip do arquivo .sql.gz, o que resultou no erro "binário" ao importar. Descobri que o arquivo estava tar / gzipado, então eu tive que tar xvf o arquivo primeiro e depois me permitiu importá-lo.
seanbreeden

8

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

Veja: notepad ++ convertendo arquivo codificado ansi para utf-8

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


3
Obrigado. Isso funcionou para mim. Abra o arquivo no NotePad ++. Codificação> Converter para UTF 8.
Abhijeet Nagre

Observe também a mudança significativa no tamanho do arquivo depois de 'salvar como' o arquivo .sql existente com codificação utf-8! Quase metade do tamanho em comparação com o arquivo fornecido. No meu caso, o mysqldump foi feito usando um Windows Power Shell, aquele programa bagunçou a codificação.
tusar

6

Eu tive este erro uma vez, depois de executar mysqldumpno Windows PowerShell assim:

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 mudá-lo para este (pipe 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!


Estou recebendo mysqldump: Got errno 32 on
Radu

Veja se este tópico pode ajudá-lo: stackoverflow.com/questions/22288271/…
Ifedi Okonkwo

Obrigado. O problema era que eu exportei o banco de dados com uma versão antiga do phpmyadmin em um servidor mysql antigo. Não sei por que, mas metade do banco de dados foi exportado em texto não criptografado e a outra metade compactada com gzip.
Radu

5

Pode ser que seu dump.sql tenha um caractere de lixo no início do seu arquivo ou uma linha em branco no início.


5

Se você não tem espaço suficiente ou não quer perder tempo descompactando-o, tente este comando.

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

Não se esqueça de substituir compressed-sqlfile.gz pelo nome do arquivo compactado.

A restauração .gz não funcionará sem o comando fornecido acima.


3

É necessário arquivar o problema dump.sql. Use o Sequel Pro para verificar o ecoding do arquivo. Deve haver caracteres ilegíveis no dump.sql.


3

Eu tive o mesmo problema, mas descobri que o arquivo de despejo era na verdade um backup do MSSQL Server, não do MySQL.

Às vezes, os arquivos de backup legados nos enganam. Verifique seu arquivo de despejo.

Na janela do terminal:

~$ cat mybackup.dmp 

O resultado foi:

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

Para parar de processar o comando cat:

CTRL + C


1

O arquivo que você está tentando importar é um arquivo zip. Descompacte o arquivo e tente importá-lo novamente.


1

No Linux, descompacte o arquivo usando gunzip. Edite o arquivo descompacte sql usando

vi unzipsqlfile.sql

Remova a primeira linha binária com esc dd vá para o final do arquivo com esc shift g remova a última linha binária com dd salve o arquivo esc x: Em seguida, reimporte para mysql com:

mysql -u username -p new_database <unzipsqlfile.sql

Fiz isso com um arquivo sql 20go de um backup jetbackup cpanel mysql. Tenha paciência para esperar vi fazendo o trabalho para arquivos grandes


0

Seu arquivo deve ter apenas extensão .sql, (.zip, .gz .rar), etc., não será compatível. exemplo: dump.sql


0

Você pode usar isso para corrigir o erro:

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

2
Por quê? Explique como isso responde à pergunta.
Yunnosch,

0

Sei que a questão dos pôsteres originais foi resolvida, mas vim aqui através do Google e as várias respostas eventualmente me levaram a descobrir que meu SQL foi despejado com um conjunto de caracteres padrão diferente daquele usado para importá-lo. Recebi o mesmo erro da pergunta original, mas como nosso despejo foi canalizado para outro cliente MySQL, não poderíamos seguir o caminho de abri-lo com outra ferramenta e salvá-lo de forma diferente.

Para nós, a solução acabou sendo a --default-character-set=utf8mb4opção, tanto na chamada de mysqldumpquanto na chamada de importação via mysql. Claro, o valor do parâmetro pode ser diferente para outros que enfrentam o mesmo problema, é apenas importante mantê-lo igual, já que a configuração padrão dos servidores (ou das ferramentas) pode ser qualquer conjunto de caracteres.


Você se importaria de compartilhar toda a string que escreveu? Como estou passando pela mesma situação que você. Ainda não tenho certeza de por que não está funcionando para mim. está no mesmo servidor, tentando fazer um teste de um site com o mysqldump -uUSER -p user_db | gzip > user_db_$(date +"%Y%m%d_%H%M").sql.gzentão tentando importá-lo usandogunzip -c user_db_datetime.sql.gz | mysql -uUSER -p user_db
Romeo Patrick

Nossa string não seria útil para você, pois é uma coleção enorme de várias configurações personalizadas. Da maneira como você descreve sua situação, minha resposta não se aplica: meu problema surgiu porque o computador / conexão despejando uma configuração diferente da de restauração, então precisamos especificar o conjunto de caracteres padrão para forçá-los a serem idênticos.
Torque de

0

Velho mas bom!

No MacOS (Catalina 10.15.7) foi um pouco estranho: eu tive que renomear meu dump.sqlpara dump.zipe depois disso, eu tive que usar o finder (!) Para descompactá-lo. no terminal, unzip dump.zipoder tar xfz dump.sql[or .gz .tar ...]leva a mensagens de erro.

Finalmente, o finder descompactou-o totalmente bem, depois disso eu pude importar o arquivo sem problemas.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.