Jestem zupełnie nowy w MySQL i uruchamiam go w systemie Windows. Próbuję przywrócić bazę danych z pliku zrzutu w MySQL, ale pojawia się następujący błąd:

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

Próbowałem, $ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sqlale otrzymałem następujące. ERROR at line 1: Unknown command '\☻'. Jest to plik zrzutu 500 Mb, a kiedy przeglądam jego zawartość za pomocą gVIM, widzę tylko wyrażenia i dane, które nie są zrozumiałe. Również gdy próbuję skopiować zawartość z pliku, aby opublikować tutaj, wszystko, co mogę skopiować, to: SQLite format 3Ten rodzaj wydaje się dziwny.

Odniesienie do --binary-mode(wprowadzone w MySQL 5.6.3) prawdopodobnie rozprasza uwagę.

Nie brzmi to tak, jakbyś miał do czynienia z plikiem wyjściowym mysqldump. Wypróbuj filenarzędzie.

shell> file dumpfile.sql
dumpfile.sql: ASCII text

Jeśli nie otrzymasz ASCII textodpowiedzi, masz do czynienia z czymś, co wcale nie jest plikiem zrzutu mysqldumplub masz do czynienia z czymś, co zostało skompresowane (na przykład za pomocą gzip lub bzip2), które „ d trzeba go zdekompresować przed wpompowaniem mysql.

Jeśli widzisz, SQLite 3.x databaseto na pewno masz odpowiedź ... to surowa baza danych SQLite, a nie plik zrzutu MySQL.

Rzeczywiście pierwsze kilka bajtów bazy danych SQLite to:

53 51 4C 69 74 65 20 66  SQLite f
6F 72 6D 61 74 20 33 00  ormat 3^@

Zauważ, że 16 oktet tutaj to 0x00, co wyjaśnia ERROR: ASCII '\0' appeared in the statement...komunikat w tym przypadku. --binary-modeWłaściwą sugestią jest fałszywy alarm.

Użytkownicy systemu Windows: narzędzie „plik” jest narzędziem systemu Unix, ale wersję systemu Windows można znaleźć tutaj .

Windows

Utwórz pliki zrzutu za pomocą tego polecenia

.\mysqldump [dbname] -r [filename.sql]

Za pomocą:

.\mysqldumb --help

-r, --result-file = nazwa

                 Direct output to a given file. This option should be used
                 in systems (e.g., DOS, Windows) that use carriage-return
                 linefeed pairs (\r\n) to separate text lines. This option
                 ensures that only a single newline is used.

Miałem ten błąd jeden raz, po uruchomieniu mysqldumpw Windows PowerShell w taki sposób:

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

To, co zrobiłem, to zmieniłem na to (potok zamiast 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

Problem zniknął!

Ja też w PowerShell

Napotkałem ten problem, gdy korzystałem z programu PowerShell do wywoływania mysqldump i > do przesyłania danych wyjściowych do pliku. Program PowerShell używał niepoprawnego kodowania podczas tworzenia pliku i przy próbie zaimportowania pliku przy użyciu mysql pojawił się ten sam błąd . <Exported-file.sql

Odkryłem, że ustawienie domyślnego kodowania na UTF8 w sesji PowerShell rozwiązało ten problem.

Moja rozdzielczość - Testowany PowerShell 5.1:

$PSDefaultParameterValues["Out-File:Encoding"] = "utf8";

Przykład: jak tworzyłem eksport (uproszczony) :

$cmdExportDB = "mysqldump --host $Host --databases $DbName -u $UID =p$PWD > $fileName";
Invoke-Expression "& $cmdExportDB";

Uwaga: Odkryto, że to nie działa w PowerShell 4.0

Moje środowisko programistyczne działało w wersji 5.1, ale prod ma wersję 4.0, a moja początkowa poprawka nie działa w starszych wersjach programu PowerShell.

Potrzebuję użyć | Set-Content -Encoding UTF8 $fileName

Zasugerował to już Ifedi

Czy próbowałeś otworzyć w Notatniku ++ (lub innym edytorze) i przekonwertować / zapisać nas do UTF-8?

Zobacz: /programming/7256049/notepad-converting-ansi-encoded-file-to-utf-8

Inną opcją może być użycie textwrangle do otwarcia i zapisania pliku jako UTF-8: http://www.barebones.com/products/textwrangler/

Ktoś przysłał mi skompresowany gtar. Nie był nawet zbyt dobrze zaznajomiony z gtar, ale jest to kolejny format kompresji.

$ file core_production-1432173533.sql.gtar
core_production-1432173533.sql.gtar: gzip compressed data, from Unix, last modified: Wed May 20 21:59:31 2015

Byłem jednak w stanie zdekompresować go tak jak zwykle:

tar -zxvf core_production-1432173533.sql.gtar
$ file core_production-1432173533.sql
core_production-1432173533.sql: ASCII text, with very long lines

A potem mógłbym wykonać import:

mysql -u root -p -h localhost core_production < core_production-1432173533.sql

Rozwiązanie: Wyodrębnij plik kopii zapasowej, a następnie przywróć ten wypakowany zrzut SQL.

Przykład:

Kopia zapasowa została pobrana jako plik dump.sql.gz i wypakuj ją za pomocą cmd gunzip w następujący sposób,

shell>  gunzip dump.sql.gz

I PRZYWRACANIE wyodrębnił plik dump.sql.

Zobacz: Informacje o trybie binarnym i interaktywnym MySQL.

http://dev.mysql.com/doc/refman/5.7/en/mysql-command-options.html#option_mysql_binary-mode

Działa dla mnie i wszystko gotowe !!

W moim przypadku plik został uszkodzony. Baza danych została skompresowana z rozszerzeniem, .bz2ale tak naprawdę była .tar.bz2.

Dekompresowanie za pomocą bzip2 -dknie powoduje żadnych błędów i generuje plik. Użycie polecenia filena wyjściach pliku, bzip2 compressed data, block size = 900kaby nawet nie wyglądało źle, aby go użyć.

Musiałem użyć tar -xf myfile.bz2