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


96

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.


mysql -u root -p -h localhost -D cơ sở dữ liệu --binary-mode -o <dump.sql
Nick

Điều đó tạo ra LỖI ở dòng 1: Lệnh không xác định '\ ☻'.
dùng1434997

Tôi đã gặp lỗi này nhưng đã nhận được một kết xuất MySQL mới và đã thử nhập lại và nó hoạt động tốt. MySQL dump của chúng tôi có hai phần được nén phải được nối và sau đó được giải nén. Tôi nghĩ rằng quá trình giải nén ban đầu đã bị gián đoạn, dẫn đến một .sqltệp có các ký tự và mã hóa kỳ lạ. Nỗ lực thứ hai hoạt động tốt.
Joshua Pinter

Câu trả lời:


217

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


12
Thiên tài. Cảm ơn bạn!
klm123

2
Bạn có nghĩa là zip và sau đó giải nén?
J86

13
Đây là cách nó hoạt động đối với tôi, giải nén db.sql.gz, bạn sẽ nhận được db.sql, đổi tên lại thành db.sql.gz, không nén nó, chỉ cần đổi tên, sau đó giải nén lại thành db.sql và bây giờ bạn sẽ nhận được tệp phù hợp để nhập.
MotsManish

@MotsManish Nghiêm túc? Tôi nghĩ đây là một trò đùa. Tôi sẽ thử xem nó có hiệu quả không.
Joshua Pinter,

3
cọ mặt 🤦‍♀️🤦‍♀️🤦‍♀️🤦‍♀️
Rambatino

53

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


mysqldump <dbname> -r <filename> cho bất kỳ ai sử dụng hệ thống Windows hoặc DOS thì đây là giải pháp. Chuyển đổi tệp UTF-8 là một sự phân tâm. Sử dụng tùy chọn -r, hướng đầu ra tới tên tệp và xử lý dòng cấp dữ liệu xuống dòng CRLF (\ r \ n) mà cửa sổ đặt trong tệp, đây là nơi có vấn đề. Cảm ơn vì Giải pháp tuyệt vời!
Timothy LJ Stewart

4
Trên một lưu ý thực tế, tôi đã giải quyết vấn đề này sau khi tạo tệp trong Powershell bằng cách chuyển đổi tệp được tạo thành UTF-8 bằng Notepad ++.
Peter Majeed

Câu trả lời này, nếu tôi không tìm hiểu kỹ, sẽ giúp tôi tiết kiệm hàng giờ tìm kiếm câu trả lời chính xác. Ước gì tôi có thể ủng hộ nhiều hơn một lần.
sam452 28/12/18

Tôi đã làm giống như @PeterMajeed. Chuyển đổi và lưu nhanh với NotePad ++ cho phép tôi khôi phục tệp hiện có
Stephen R

18

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.


Điều này phù hợp với tôi đối với tệp sao lưu SQL đã được tạo bằng cách chạy mysqldump qua Powershell. Đầu ra Poweshell là UTF-16. Thay đổi thành UTF-8 đã giải quyết được vấn đề và cho phép tôi khôi phục cơ sở dữ liệu của mình từ tệp sao lưu.
Harry Mantheakis

9

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

1
Đây là câu trả lời cho tôi. Lúc đầu, tôi đã nén tệp .sql.gz vào, dẫn đến lỗi "nhị phân" khi nhập. Hóa ra tệp đã được tar / gzipped nên tôi phải tar xvf tệp trước rồi mới cho phép tôi nhập.
seanbreeden

8

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/


3
Cảm ơn. Điều này đã làm các mẹo cho tôi. Mở tệp trong NotePad ++. Mã hóa> Chuyển đổi sang UTF 8.
Abhijeet Nagre

Cũng lưu ý sự thay đổi đáng kể về kích thước tệp sau khi bạn 'lưu Dưới dạng' tệp .sql hiện có với mã hóa utf-8! Gần một nửa kích thước so với tệp đã cho. Trong trường hợp của tôi, mysqldump đã được sử dụng Windows Power Shell, chương trình đó đã làm rối loạn mã hóa.
tusar

6

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!


Tôi đang nhận được mysqldump: Got errno 32 trên
Radu

Xem chủ đề này có thể có thể giúp bạn: stackoverflow.com/questions/22288271/...
Ifedi Okonkwo

Cảm ơn bạn. Vấn đề là tôi đã xuất db với phiên bản cũ của phpmyadmin trên máy chủ mysql cũ. Không chắc tại sao nhưng một nửa cơ sở dữ liệu được xuất dưới dạng văn bản rõ ràng và nửa còn lại là gzip-ed.
Radu

5

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.


5

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.


3

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.


3

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


1

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.


1

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


0

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


0

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

2
Tại sao? Vui lòng giải thích cách nó tồn tại câu hỏi.
Yunnosch

0

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.


Bạn có phiền chia sẻ toàn bộ chuỗi bạn đã viết không? Như tôi cũng đang gặp trường hợp giống bạn. Tôi mặc dù vẫn không chắc tại sao nó không hoạt động với tôi. nó nằm trên cùng một máy chủ, cố gắng tạo một dàn trang web với mysqldump -uUSER -p user_db | gzip > user_db_$(date +"%Y%m%d_%H%M").sql.gzsau đó cố gắng nhập nó bằng cách sử dụnggunzip -c user_db_datetime.sql.gz | mysql -uUSER -p user_db
Romeo Patrick

Chuỗi của chúng tôi sẽ không hữu ích cho bạn, vì nó là một bộ sưu tập khổng lồ các cài đặt tùy chỉnh khác nhau. Theo cách bạn mô tả tình huống của mình, câu trả lời của tôi sẽ không áp dụng: vấn đề của tôi phát sinh từ máy tính kết xuất / kết nối là một thiết lập khác với thiết lập khôi phục, vì vậy chúng tôi cần chỉ định bộ ký tự mặc định để buộc chúng giống hệt nhau.
Mô-men xoắn

0

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ố.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.