Bật chế độ nhị phân trong khi khôi phục Cơ sở dữ liệu từ kết xuất SQL

Tôi rất mới với MySQL và đang chạy nó trên Windows. Tôi đang cố gắng khôi phục Cơ sở dữ liệu từ tệp kết xuất trong MySQL, nhưng tôi gặp lỗi sau:

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

Tôi đã thử đưa --binary-modevào tệp ini nhưng nó vẫn báo lỗi tương tự. Tôi nên làm gì? Xin vui lòng giúp đỡ.

CẬP NHẬT

Theo đề xuất của Nick trong nhận xét của anh ấy, tôi đã thử $ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sqlnhưng nó cho tôi những điều sau ERROR at line 1: Unknown command '\☻'. Đây là một tệp kết xuất 500 Mb và khi tôi xem nội dung của nó bằng gVIM, tất cả những gì tôi có thể thấy là các biểu thức và dữ liệu không thể hiểu được.

Giải nén tệp, sau đó nhập lại.

Tôi gặp vấn đề tương tự trong cửa sổ khôi phục tệp kết xuất. Tệp kết xuất của tôi đã được tạo bằng windows powershell và mysqldump như:

mysqldump db > dump.sql

Vấn đề xuất phát từ mã hóa mặc định của powershell là UTF16. Để tìm hiểu sâu hơn về vấn đề này, chúng ta có thể sử dụng tiện ích "tệp" của GNU, và có một phiên bản windows ở đây .
Đầu ra của tệp kết xuất của tôi là:

Văn bản Unicode UTF-16 nhỏ cuối cùng, với các dòng rất dài, với các dấu cuối dòng CRLF.

Sau đó, chuyển đổi hệ thống mã hóa là cần thiết và có nhiều phần mềm khác nhau có thể làm điều này. Ví dụ trong emacs,

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

sau đó nhập hệ thống mã hóa yêu cầu như utf-8.

Và trong tương lai, để có kết quả mysqldump tốt hơn, hãy sử dụng:

mysqldump <dbname> -r <filename>

và sau đó đầu ra được xử lý bởi mysqldumpchính nó nhưng không chuyển hướng của powershell.

tham khảo: /dba/44721/error-ately-restoring-a-database-from-an-sql-dump

Trong máy Windows, vui lòng làm theo các bước trước.

1. Mở tệp trong notepad.
2. Nhấp vào Lưu dưới dạng
3. Chọn Kiểu mã hóa UTF-8.

Bây giờ nguồn db của bạn.

Giải nén tệp của bạn bằng công cụ lưu trữ Tar. bạn có thể sử dụng nó theo cách này:

tar xf example.sql.gz

Bạn đã thử mở trong notepad ++ (hoặc một trình soạn thảo khác) và chuyển đổi / lưu chúng tôi thành UTF-8 chưa?

Xem: notepad ++ chuyển đổi tệp được mã hóa ansi thành utf-8

Một tùy chọn khác có thể là sử dụng textwrangle để mở và lưu tệp dưới dạng UTF-8: http://www.barevial.com/products/textwrangler/

Tôi đã gặp lỗi này một lần, sau khi chạy mysqldumptrên Windows PowerShell như sau:

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

Những gì tôi đã làm là thay đổi nó thành này (đường dẫn thay vì 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

Và vấn đề đã biến mất!

Có thể là dump.sql của bạn có ký tự rác ở đầu tệp của bạn hoặc có một dòng trống ở đầu.

Nếu bạn không có đủ dung lượng hoặc không muốn mất thời gian giải nén, hãy thử lệnh này.

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

Đừng quên thay thế nén-sqlfile.gz bằng tên tệp nén của bạn.

.gz restore sẽ không hoạt động nếu không có lệnh mà tôi đã cung cấp ở trên.

Vấn đề là bạn phải tập tin dump.sql. Sử dụng Sequel Pro, hãy kiểm tra mã hóa tập tin của bạn. Nó phải là các ký tự rác trong dump.sql của bạn.

Tôi gặp vấn đề tương tự, nhưng phát hiện ra rằng tệp kết xuất thực sự là một bản sao lưu MSSQL Server, không phải MySQL.

Đôi khi các tệp sao lưu kế thừa có thể đánh lừa chúng ta Kiểm tra tệp kết xuất của bạn.

Trên cửa sổ đầu cuối:

~$ cat mybackup.dmp 

Kết quả là:

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

Để dừng xử lý lệnh cat:

CTRL + C

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

Tệp bạn đang cố gắng nhập là tệp zip. Giải nén tệp và sau đó thử nhập lại.

Trong linux Giải nén tệp của bạn bằng gunzip Chỉnh sửa tệp sql giải nén của bạn bằng

vi unzipsqlfile.sql

Xóa dòng nhị phân đầu tiên với esc dd đi đến cuối tệp với esc shift g xóa dòng nhị phân cuối cùng với dd lưu tệp esc x: Sau đó nhập lại vào mysql với:

tên người dùng mysql -u -p new_database <unzipsqlfile.sql

Tôi đã thực hiện điều đó với một tệp sql 20go từ bản sao lưu mysql cpanel jetbackup. Hãy kiên nhẫn chờ đợi vi thực hiện công việc cho các tệp lớn

Tệp của bạn chỉ nên là phần mở rộng .sql, (.zip, .gz .rar), v.v. sẽ không hỗ trợ. ví dụ: dump.sql

Bạn có thể sử dụng điều này để sửa lỗi:

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

Tôi biết câu hỏi áp phích ban đầu đã được giải quyết, nhưng tôi đến đây thông qua Google, và các câu trả lời khác nhau cuối cùng đã khiến tôi phát hiện ra rằng SQL của tôi đã được kết xuất với một bộ ký tự mặc định khác với bộ được sử dụng để nhập nó. Tôi gặp lỗi tương tự như câu hỏi ban đầu, nhưng khi kết xuất của chúng tôi được đưa vào một máy khách MySQL khác, chúng tôi không thể mở nó bằng một công cụ khác và lưu nó theo cách khác.

Đối với chúng tôi, giải pháp hóa ra là một --default-character-set=utf8mb4lựa chọn, được sử dụng cả khi gọi mysqldumpcũng như gọi nhập nó qua mysql. Tất nhiên, giá trị của tham số có thể khác nhau đối với những người khác gặp phải cùng một vấn đề, điều quan trọng là phải giữ nguyên giá trị đó, vì cài đặt mặc định của máy chủ (hoặc công cụ) có thể là bất kỳ bộ ký tự nào.

Cũ nhưng quý!

Trên MacOS (Catalina 10.15.7) có một chút kỳ lạ: tôi phải đổi tên dump.sqlthành dump.zipvà sau đó, tôi phải sử dụng công cụ tìm (!) Để giải nén nó. trong thiết bị đầu cuối, unzip dump.zipoder tar xfz dump.sql[or .gz .tar ...]dẫn đến các tin nhắn lỗi.

Cuối cùng, finder đã giải nén nó hoàn toàn tốt, sau đó tôi có thể nhập tệp mà không gặp sự cố.