Bir SQL dökümünden bir Veritabanını geri yüklerken ikili modu etkinleştirin

MySQL konusunda son derece yeniyim ve onu Windows üzerinde çalıştırıyorum. MySQL'deki bir döküm dosyasından bir Veritabanını geri yüklemeye çalışıyorum, ancak aşağıdaki hatayı alıyorum:

$ >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-modeİni dosyasını koymayı denedim ama yine de aynı hatayı veriyor. Ne yapmalıyım? Lütfen yardım et.

GÜNCELLEME

Nick'in yorumunda önerdiği gibi denedim $ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sqlama bana şu verdi ERROR at line 1: Unknown command '\☻'. Bu 500 Mb'lik bir döküm dosyası ve içeriğini gVIM kullanarak görüntülediğimde, görebildiğim tek şey anlaşılmaz ifadeler ve veriler.

Dosyayı açın ve ardından tekrar içe aktarın.

Aynı sorunu bir döküm dosyasını geri yükleyen pencerelerde karşılaşıyorum. Döküm dosyam Windows powershell ve mysqldump ile oluşturuldu:

mysqldump db > dump.sql

Sorun, powershell'in varsayılan kodlamasından kaynaklanıyor UTF16. Derin bu içine bakmak için, GNU "dosyası" programını kullanabilir ve bir windows sürümü vardır burada .
Döküm dosyamın çıktısı:

CRLF hat sonlandırıcıları ile çok uzun satırlara sahip küçük endian UTF-16 Unicode metni.

Daha sonra bir kodlama sistemi dönüşümü gerekir ve bunu yapabilecek çeşitli yazılımlar vardır. Örneğin emacs'de,

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

daha sonra utf-8 gibi gerekli kodlama sistemini girin.

Ve gelecekte, daha iyi bir mysqldump sonucu için şunu kullanın:

mysqldump <dbname> -r <filename>

ve sonra çıktı mysqldumpkendi başına ele alınır, ancak powershell'in yeniden yönlendirilmesi değil.

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

Windows makinesinde, lütfen önceki adımları izleyin.

1. Dosyayı not defterinde açın.
2. Farklı kaydet'e tıklayın
3. Kodlama türünü UTF-8 seçin.

Şimdi db'nizi kaynaklayın.

Tar arşivleme aracıyla dosyanızı çıkarın. şu şekilde kullanabilirsiniz:

tar xf example.sql.gz

Notepad ++ (veya başka bir düzenleyicide) açmayı ve bizi UTF-8'e dönüştürmeyi / kaydetmeyi denediniz mi?

Bakınız: notepad ++ ansi kodlu dosyayı utf-8'e dönüştürme

Diğer bir seçenek, dosyayı UTF-8 olarak açmak ve kaydetmek için textwrangle kullanmak olabilir: http://www.barebones.com/products/textwrangler/

mysqldumpWindows PowerShell'de şu şekilde çalıştırdıktan sonra bu hatayı bir kez yaşadım :

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

Bunu şu şekilde değiştirdim (Set-Content yerine boru):

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

Ve sorun ortadan kalktı!

Dump.sql dosyanızın başında çöp karakteri olabilir veya başında boş bir satır olabilir.

Yeterli alanınız yoksa veya açmak için zaman harcamak istemiyorsanız, bu komutu deneyin.

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

Compressed-sqlfile.gz dosyasını sıkıştırılmış dosya adınızla değiştirmeyi unutmayın.

.gz geri yükleme, yukarıda verdiğim komut olmadan çalışmayacaktır.

Dump.sql problemini dosyalamalısınız.Sequel Pro dosyasını ecoding olarak kontrol edin. Dump.sql dosyanızda gereksiz karakterler olmalıdır.

Aynı sorunu yaşadım, ancak döküm dosyasının MySQL değil, aslında bir MSSQL Sunucusu yedeği olduğunu öğrendim.

Bazen eski yedekleme dosyaları bize oyun oynar. Döküm dosyanızı kontrol edin.

Terminal penceresinde:

~$ cat mybackup.dmp 

Sonuç şuydu:

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

Cat komutunu işlemeyi durdurmak için:

CTRL + C

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

İçe aktarmaya çalıştığınız dosya bir zip dosyasıdır. Dosyayı açın ve tekrar içe aktarmayı deneyin.

Linux altında gunzip kullanarak dosyanızı açın. Unzip sql dosyanızı şunu kullanarak düzenleyin:

vi unzipsqlfile.sql

Esc dd ile ilk ikili satırı kaldırın esc shift ile dosyanın altına gidin g son ikili satırı dd ile kaldırın esc x dosyasını kaydedin: Sonra mysql'e şu şekilde yeniden aktarın:

mysql -u kullanıcı adı -p new_database <unzipsqlfile.sql

Bunu bir jetbackup cpanel mysql yedeğinden bir 20go sql dosyasıyla gerçekleştirdim. Büyük dosyalar için işi yaparken beklemek için sabırlı olun

Dosyanız sadece .sql uzantısı olmalıdır, (.zip, .gz .rar) vb. Desteklemeyecektir. örnek: dump.sql

Hatayı düzeltmek için bunu kullanabilirsiniz:

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

Orijinal poster sorusunun çözüldüğünü biliyorum, ancak buraya Google aracılığıyla geldim ve çeşitli yanıtlar sonunda beni SQL'imin, onu içe aktarmak için kullanılandan farklı bir varsayılan karakter kümesiyle döküldüğünü keşfetmeye yönlendirdi. Orijinal soruyla aynı hatayı aldım, ancak dökümümüz başka bir MySQL istemcisine aktarıldığından, onu başka bir araçla açıp farklı şekilde kaydetme yoluna gidemedik.

Bizim için çözüm olduğu ortaya çıktı --default-character-set=utf8mb4seçeneği çağrısına hem kullanılmak üzere mysqldumpyanı sıra yoluyla almak için çağrı mysql. Tabii ki, parametrenin değeri aynı sorunla karşılaşan diğer kişiler için farklı olabilir, sunucuların (veya araçların) varsayılan ayarı herhangi bir karakter kümesi olabileceğinden, onu aynı tutmak önemlidir.

Eski ama altın!

MacOS'ta (Catalina 10.15.7) biraz tuhaftı: kendimi dump.sqliçine yeniden adlandırmak zorunda kaldım dump.zipve bundan sonra, onu açmak için bulucu (!) Kullanmam gerekti . terminalde, unzip dump.zipoder tar xfz dump.sql[or .gz .tar ...]hata mesajlarına yol açar.

Son olarak, bulucu onu tamamen iyi bir şekilde açtı, bundan sonra dosyayı sorunsuz bir şekilde içe aktarabilirim.