Ошибка при восстановлении базы данных из дампа SQL


14

Я чрезвычайно новичок в MySQL и работаю на Windows. Я пытаюсь восстановить базу данных из файла дампа в MySQL, но получаю следующую ошибку:

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

Я попытался, $ > mysql -u root -p -h localhost -D database --binary-mode -o < dump.sqlно это дало мне следующее. ERROR at line 1: Unknown command '\☻'. Это файл дампа 500 Мб, и когда я просматриваю его содержимое с помощью gVIM, я вижу только выражения и данные, которые не понятны. Кроме того, когда я пытаюсь скопировать содержимое из файла, чтобы опубликовать здесь, все, что я могу скопировать, это: SQLite format 3Этот вид кажется странным.


1
Вы тот, кто взял резервную копию?
Мениос

Я получал эту ошибку, но получил новый дамп MySQL и попытался повторно импортировать, и это работало отлично. Наш дамп MySQL состоит из двух частей, которые нужно соединить, а затем разархивировать. Я думаю, что первоначальное распаковывание было прервано, что привело к созданию .sqlфайла со странными символами и кодировками. Вторая попытка работала нормально.
Джошуа Пинтер

Ответы:


18

Ссылка на --binary-mode(введенная в MySQL 5.6.3), вероятно, отвлекает.

Там не похоже, что вы имеете дело с выходным файлом mysqldump. Попробуйте fileутилиту.

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

Если вы не получили ASCII textответ, вы имеете дело с чем-то, что вообще не является файлом дампа mysqldump, или вы имеете дело с чем-то сжатым (например, с помощью gzip или bzip2), который вы ' Мне нужно разархивировать, прежде чем обвязать его mysql.

Если вы видите, у SQLite 3.x databaseвас точно есть ответ ... это необработанная база данных SQLite, а не файл дампа MySQL.

Действительно, первые несколько байтов базы данных SQLite:

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

Обратите внимание, что 16-й октет здесь равен 0x00, что объясняет ERROR: ASCII '\0' appeared in the statement...сообщение в этом случае. Предположение о том , что --binary-modeподходит ложная тревога.


Пользователи Windows: утилита 'file' - это инструмент от Unix, но версию для Windows можно найти здесь .


Я получаю эту ошибку и при запуске file MySQL.sqlвозвращается UTF-8 Unicode text, with very long lines. Есть идеи?
Джошуа Пинтер

@JoshuaPinter попробуйте less -S MySQL.sql. Что ты видишь? Это похоже на файл дампа MySQL? Они по большей части читаемы человеком. (Используйте qдля выхода.)
Майкл - sqlbot

1
Да, первая строка выглядит так -- MySQL dump 10.13 Distrib 5.7.22, for Linux (x86_64). И перемещение вниз через пробел показывает типичные инструкции MySQL. Однако, если я продолжу идти вниз, он зависнет на определенной линии. Та же самая строка, которая появилась в сообщении об ошибке. Я углубился в это и обнаружил, что дамп MySQL не был правильно разархивирован в первый раз. Не уверен, что пошло не так, но когда я разархивировал, он работает нормально. Я добавил ответ об этом здесь для других: stackoverflow.com/a/51432853/293280 Большое спасибо за вашу помощь и быстрый ответ. 👍
Джошуа Пинтер

6

Windows

Создайте файлы дампа с помощью этой команды

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

С помощью:

.\mysqldumb --help

-r, --result-file = имя

                 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.

2
Это правильный ответ. Powershell> создает файл в кодировке UTF-16, который вызывает проблемы. Найдите Powershell здесь: dev.mysql.com/doc/refman/5.7/ru/mysqldump.html
SimZal,

1

У меня была эта ошибка однажды, после запуска mysqldumpна Windows PowerShell, например, так:

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

Что я сделал, так это изменил это (труба вместо 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

И проблема ушла!


1

Я тоже в PowerShell

Я столкнулся с этой проблемой, когда использовал PowerShell для вызова mysqldump и > для передачи вывода в файл. PowerShell использовал неправильную кодировку при создании файла, и я получил ту же ошибку при попытке импортировать файл с помощью mysql .. <exported-file.sql

Я обнаружил, что установка кодировки по умолчанию UTF8 в сеансе PowerShell решает эту проблему.

Мое разрешение - Проверено PowerShell 5.1:

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

Пример: как я производил экспорт (упрощенно) :

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

Примечание. Обнаружено, что это не работает в PowerShell 4.0

Моя среда разработки работала на 5.1, но prod на 4.0, и мое первоначальное исправление не работает в старых версиях PowerShell.

Нужно использовать | Set-Content -Encoding UTF8 $fileName

Это было уже предложено Ифеди



0

Кто-то прислал мне сжатый гтарь. Даже не был слишком знаком с gtar, но это еще один формат сжатия.

$ 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

Однако я смог распаковать его так же, как обычно:

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

И тогда я мог бы сделать импорт:

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

0

Решение: Извлеките файл резервной копии, а затем восстановите этот извлеченный дамп sql.

Пример :

Резервная копия была взята в виде файла dump.sql.gz и распакована с использованием gunzip cmd следующим образом:

shell>  gunzip dump.sql.gz

И восстановите извлеченный файл dump.sql.

Ссылка: О бинарном и интерактивном режиме MySQL.

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

Это работает для меня, и все готово!


0

В моем случае файл был поврежден. База данных была сжата с расширением, .bz2но это было на самом деле .tar.bz2.

Распаковка с использованием bzip2 -dkне выводит никаких ошибок и генерирует файл. Использование команды fileв выходных файлах, bzip2 compressed data, block size = 900kчтобы ее использование не выглядело даже неправильно.

Я должен был использовать tar -xf myfile.bz2

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.