Błąd podczas przywracania bazy danych z zrzutu SQL

14

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.

użytkownik1434997
źródło
1
Czy to ty zrobiłeś kopię zapasową?
Menios,
Otrzymywałem ten błąd, ale otrzymałem nowy zrzut MySQL i spróbowałem ponownie zaimportować i działało dobrze. Nasz zrzut MySQL składa się z dwóch spakowanych części, które należy połączyć, a następnie rozpakować. Myślę, że początkowe rozpakowanie zostało przerwane, co spowodowało utworzenie .sqlpliku z dziwnymi znakami i kodowaniem. Druga próba zadziałała dobrze.
Joshua Pinter

Odpowiedzi:

18

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 .

Michael - sqlbot
źródło
Otrzymuję ten błąd i po uruchomieniu file MySQL.sqlpowraca UTF-8 Unicode text, with very long lines. Jakieś pomysły?
Joshua Pinter
@JoshuaPinter spróbuj less -S MySQL.sql. Co widzisz? Czy to wygląda jak plik zrzutu MySQL? Są one w większości czytelne dla człowieka. (Użyj, qaby wyjść.)
Michael - sqlbot
1
Tak, wygląda pierwsza linia -- MySQL dump 10.13 Distrib 5.7.22, for Linux (x86_64). I przejście w dół za pomocą spacji pokazuje typowe instrukcje MySQL. Jeśli jednak będę dalej schodzić, zawiesi się na pewnej linii. Ten sam wiersz, który pojawił się w komunikacie o błędzie. Przyjrzałem się temu dalej i odkryłem, że zrzut MySQL nie został poprawnie rozpakowany za pierwszym razem. Nie jestem pewien, co poszło nie tak, ale kiedy ponownie rozpakuję, działa dobrze. Tutaj dodałem odpowiedź na ten temat dla innych: stackoverflow.com/a/51432853/293280 Dziękuję bardzo za pomoc i szybką odpowiedź. 👍
Joshua Pinter
6

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.
Timothy LJ Stewart
źródło
2
To jest poprawna odpowiedź. Powershell's> tworzy plik zakodowany w UTF-16, który powoduje problemy. Wyszukaj Powershell tutaj: dev.mysql.com/doc/refman/5.7/en/mysqldump.html
SimZal
1

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ął!

Ifedi Okonkwo
źródło
1

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

Mikołaj
źródło
0

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
Donato
źródło
0

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 !!

lalit
źródło
0

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

kod potwora
źródło