SQLダンプからデータベースを復元するときにバイナリモードを有効にする

私はMySQLを初めて使用し、Windowsで実行しています。MySQLのダンプファイルからデータベースを復元しようとしていますが、次のエラーが発生します。

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

--binary-modeiniファイルを入れてみましたが、それでも同じエラーが発生します。私は何をすべきか？助けてください。

更新

Nickがコメントで示唆し$ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sqlたようERROR at line 1: Unknown command '\☻'. に、試してみましたが、次のようになりました。500Mbのダンプファイルで、gVIMを使用してその内容を表示すると、理解できない式とデータしか表示されません。

ファイルを解凍してから、再度インポートしてください。

ダンプファイルを復元するWindowsでも同じ問題が発生します。私のダンプファイルは、次のようなWindowsPowerShellとmysqldumpで作成されました。

mysqldump db > dump.sql

問題は、PowerShellのデフォルトのエンコーディングがUTF16であることに起因します。これをさらに詳しく調べるために、GNUの「ファイル」ユーティリティを使用できます。ここにWindowsバージョンがあります。
ダンプファイルの出力は次のとおりです。

非常に長い行とCRLF行末記号を含むリトルエンディアンUTF-16Unicodeテキスト。

次に、コーディングシステムの変換が必要であり、これを実行できるさまざまなソフトウェアがあります。たとえばemacsでは、

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

次に、utf-8などの必要なコーディングシステムを入力します。

そして将来、より良いmysqldumpの結果を得るために、以下を使用してください。

mysqldump <dbname> -r <filename>

次に、出力はmysqldumpそれ自体で処理されますが、PowerShellのリダイレクトは処理されません。

参照：https：//dba.stackexchange.com/questions/44721/error-while-restoring-a-database-from-an-sql-dump

Windowsマシンでは、上記の手順に従ってください。

1. メモ帳でファイルを開きます。
2. [名前を付けて保存]をクリックします
3. エンコーディングタイプUTF-8を選択します。

次に、データベースを調達します。

Tarアーカイブツールを使用してファイルを抽出します。次のように使用できます。

tar xf example.sql.gz

notepad ++（または別のエディター）で開いて、UTF-8に変換/保存してみましたか？

参照：notepad ++ ansiエンコードファイルをutf-8に変換

別のオプションとして、textwrangleを使用してファイルをUTF-8として開いて保存することもできます：http：//www.barebones.com/products/textwrangler/

次のmysqldumpようにWindowsPowerShellで実行した後、このエラーが発生しました。

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

私がしたことはこれに変更することでした（代わりにパイプを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

そして問題はなくなりました！

dump.sqlのファイルの先頭にガベージ文字が含まれているか、先頭に空白行がある可能性があります。

十分なスペースがない場合、または解凍に時間を無駄にしたくない場合は、このコマンドを試してください。

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

compressed-sqlfile.gzを圧縮ファイル名に置き換えることを忘れないでください。

.gz restoreは、上記で提供したコマンドがないと機能しません。

dump.sqlの問題をファイルする必要があります。SequelProを使用してファイルのエンコーディングを確認してください。dump.sqlのゴミ文字である必要があります。

同じ問題が発生しましたが、ダンプファイルは実際にはMySQLではなくMSSQLServerのバックアップであることがわかりました。

時々、レガシーバックアップファイルは私たちに悪戯をします。ダンプファイルを確認してください。

ターミナルウィンドウ：

~$ cat mybackup.dmp 

結果は次のとおりです。

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

catコマンドの処理を停止するには：

CTRL + C

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

インポートしようとしているファイルはzipファイルです。ファイルを解凍してから、インポートを再試行してください。

Linuxではgunzipを使用してファイルを解凍します。を使用して解凍SQLファイルを編集します。

vi unzipsqlfile.sql

escddで最初のバイナリ行を削除しますescshiftでファイルの最後に移動しますgddで最後のバイナリ行を削除しますファイルを保存しますescx：次に：でmysqlに再インポートします

mysql -u username -p new_database <unzipsqlfile.sql

jetbackup cpanelmysqlバックアップからの20gosqlファイルを使用してこれを実行しました。大きなファイルの仕事をするviを待つのを我慢してください

ファイルは.sql拡張子のみである必要があります（.zip、.gz .rar）などはサポートされません。例：dump.sql

これを使用してエラーを修正できます。

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

元のポスターの質問が解決されたことは知っていますが、Google経由でここに来たところ、さまざまな回答から、SQLがインポートに使用されたものとは異なるデフォルトの文字セットでダンプされていることがわかりました。元の質問と同じエラーが発生しましたが、ダンプが別のMySQLクライアントにパイプされたため、別のツールで開いて別の方法で保存する方法をとることができませんでした。

私たちにとって、ソリューションは--default-character-set=utf8mb4オプションであることが判明し、の呼び出しと、mysqldumpを介してインポートする呼び出しの両方で使用されますmysql。もちろん、同じ問題に直面している他の人とはパラメーターの値が異なる場合があります。サーバー（またはツール）のデフォルト設定は任意の文字セットである可能性があるため、パラメーターを同じに保つことが重要です。

古いが金！

MacOS（Catalina 10.15.7）では、少し奇妙でした。名前をに変更dump.sqlしdump.zip、その後、finder（！）を使用して解凍する必要がありました。ターミナルでは、unzip dump.zipオーダーtar xfz dump.sql[or .gz .tar ...]はエラーメッセージにつながります。

最後に、ファインダーはそれを完全に正常に解凍しました。その後、問題なくファイルをインポートできました。