Mengaktifkan mode biner saat memulihkan Database dari dump SQL

Saya sangat baru mengenal MySQL dan menjalankannya di Windows. Saya mencoba memulihkan Database dari dumpfile di MySQL, tetapi saya mendapatkan kesalahan berikut:

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

Saya sudah mencoba memasukkan --binary-modefile ini tetapi masih memberikan kesalahan yang sama. Apa yang harus saya lakukan? Tolong bantu.

MEMPERBARUI

Seperti yang disarankan oleh Nick dalam komentarnya saya mencoba $ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sqltetapi memberi saya yang berikut ERROR at line 1: Unknown command '\☻'. Ini adalah file dump 500 Mb, dan ketika saya melihat isinya menggunakan gVIM, yang bisa saya lihat hanyalah ekspresi dan data yang tidak dapat dipahami.

Buka zip file, lalu impor lagi.

Saya menemui masalah yang sama di windows memulihkan file dump. File dump saya dibuat dengan windows PowerShell dan mysqldump seperti:

mysqldump db > dump.sql

Masalahnya berasal dari pengkodean default PowerShell adalah UTF16. Untuk melihat lebih dalam ini, kita dapat menggunakan "file" utilitas dari GNU, dan di sana ada versi jendela di sini .
Output dari file dump saya adalah:

Teks Unicode UTF-16 Little-endian, dengan baris yang sangat panjang, dengan terminator baris CRLF.

Maka diperlukan konversi sistem pengkodean, dan ada berbagai perangkat lunak yang dapat melakukan ini. Misalnya di emacs,

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

lalu masukan sistem koding yang dibutuhkan seperti utf-8.

Dan kedepannya, untuk hasil mysqldump yang lebih baik, gunakan:

mysqldump <dbname> -r <filename>

dan kemudian output ditangani dengan mysqldumpsendirinya tetapi tidak dengan pengalihan PowerShell.

referensi: /dba/44721/error- While-restoring-a-database-from-an-sql-dump

Di mesin Windows, ikuti langkah-langkah sebelumnya.

1. Buka file di notepad.
2. Klik Simpan sebagai
3. Pilih Jenis pengkodean UTF-8.

Sekarang sumber db Anda.

Ekstrak file Anda dengan alat pengarsipan Tar. Anda dapat menggunakannya dengan cara ini:

tar xf example.sql.gz

Sudahkah Anda mencoba membuka di notepad ++ (atau editor lain) dan mengonversi / menyimpan kami ke UTF-8?

Lihat: notepad ++ mengonversi file yang dikodekan ansi ke utf-8

Pilihan lain mungkin menggunakan textwrangle untuk membuka dan menyimpan file sebagai UTF-8: http://www.barebones.com/products/textwrangler/

Saya mengalami kesalahan ini sekali, setelah menjalankan mysqldumpWindows PowerShell seperti ini:

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

Apa yang saya lakukan adalah mengubahnya menjadi ini (pipa bukan ke 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

Dan masalahnya hilang!

Mungkin dump.sql Anda memiliki karakter sampah di awal file Anda atau ada baris kosong di awal.

Jika Anda tidak memiliki cukup ruang atau tidak ingin membuang waktu untuk mendekompresi, coba perintah ini.

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

Jangan lupa untuk mengganti compressed-sqlfile.gz dengan nama file terkompresi Anda.

.gz restore tidak akan berfungsi tanpa perintah yang saya berikan di atas.

Ini harus Anda mengajukan masalah dump.sql. Gunakan Sequel Pro, periksa file ecoding Anda. Seharusnya ada karakter sampah di dump.sql Anda.

Saya memiliki masalah yang sama, tetapi menemukan bahwa file dump sebenarnya adalah cadangan MSSQL Server, bukan MySQL.

Terkadang file cadangan lama mempermainkan kita. Periksa file dump Anda.

Di jendela terminal:

~$ cat mybackup.dmp 

Hasilnya adalah:

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

Untuk berhenti memproses perintah cat:

CTRL + C

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

File yang Anda coba impor adalah file zip. Buka zip file, lalu coba impor lagi.

Di bawah linux Ungzip file Anda menggunakan gunzip Edit file sql unzip Anda menggunakan

vi unzipsqlfile.sql

Hapus baris biner pertama dengan esc dd pergi ke bagian bawah file dengan esc shift g hapus baris biner terakhir dengan dd simpan file esc x: Kemudian impor kembali ke mysql dengan:

mysql -u username -p new_database <unzipsqlfile.sql

Saya melakukan itu dengan file sql 20go dari cadangan mysql cpanel jetbackup. Bersabarlah menunggu vi melakukan pekerjaan untuk file besar

File Anda seharusnya hanya berekstensi .sql, (.zip, .gz .rar) dll tidak akan mendukung. contoh: dump.sql

Anda dapat menggunakan ini untuk memperbaiki kesalahan:

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

Saya tahu pertanyaan poster asli telah diselesaikan, tetapi saya datang ke sini melalui Google, dan berbagai jawaban akhirnya membuat saya menemukan bahwa SQL saya dibuang dengan charset default yang berbeda dari yang digunakan untuk mengimpornya. Saya mendapatkan kesalahan yang sama dengan pertanyaan awal, tetapi karena dump kami disalurkan ke klien MySQL lain, kami tidak dapat membuka rute dengan alat lain dan menyimpannya secara berbeda.

Bagi kami, solusinya ternyata adalah --default-character-set=utf8mb4pilihan, untuk digunakan baik pada panggilan mysqldumpmaupun untuk mengimpornya melalui mysql. Tentu saja, nilai parameter mungkin berbeda untuk orang lain yang menghadapi masalah yang sama, yang penting adalah tetap sama, karena pengaturan default server (atau alat) mungkin berupa rangkaian karakter apa pun.

Tua tapi emas!

Di MacOS (Catalina 10.15.7) agak aneh: Saya harus mengganti nama saya dump.sqlmenjadi dump.zipdan setelah itu, saya harus menggunakan finder (!) Untuk mengekstraknya. di terminal, unzip dump.zipoder tar xfz dump.sql[or .gz .tar ...]mengarah ke pesan kesalahan.

Akhirnya, finder telah mengekstraknya dengan baik, setelah itu saya dapat mengimpor file tanpa masalah.