Включить двоичный режим при восстановлении базы данных из дампа SQL

Я новичок в 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'.

Я попытался вставить --binary-modeini-файл, но он по-прежнему дает ту же ошибку. Что я должен делать? Пожалуйста помоги.

ОБНОВИТЬ

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

Разархивируйте файл и снова импортируйте.

Я сталкиваюсь с той же проблемой в Windows, восстанавливая файл дампа. Мой файл дампа был создан с помощью Windows PowerShell и mysqldump, например:

mysqldump db > dump.sql

Проблема связана с кодировкой по умолчанию для PowerShell - UTF16. Чтобы разобраться в этом, мы можем использовать «файловую» утилиту GNU, и существует версия для Windows. здесь .
Результат моего файла дампа:

Текст Unicode UTF-16 с прямым порядком байтов, с очень длинными строками, с терминаторами строк CRLF.

Затем требуется преобразование системы кодирования, и есть различные программы, которые могут это сделать. Например, в emacs,

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

затем введите требуемую систему кодирования, такую ​​как utf-8.

И в будущем для лучшего результата mysqldump используйте:

mysqldump <dbname> -r <filename>

а затем вывод обрабатывается mysqldumpсам по себе, но не перенаправлением powershell.

ссылка: /dba/44721/error- while-restoring-a-database-from-an-sql-dump

На компьютере с Windows выполните предыдущие шаги.

1. Открыть файл в блокноте.
2. Нажмите на Сохранить как
3. Выберите тип кодировки UTF-8.

Теперь создайте свой db.

Извлеките файл с помощью инструмента архивирования Tar. вы можете использовать это так:

tar xf example.sql.gz

Вы пробовали открыть в блокноте ++ (или другом редакторе) и преобразовать / сохранить нас в UTF-8?

Смотрите: notepad ++ преобразование файла, закодированного в ansi, в utf-8

Другой вариант - использовать textwrangle для открытия и сохранения файла как UTF-8: http://www.barebones.com/products/textwrangler/

Однажды у меня была эта ошибка после запуска 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

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

Возможно, ваш dump.sql имеет символ мусора в начале вашего файла или в начале есть пустая строка.

Если у вас недостаточно места или вы не хотите тратить время на его распаковку, попробуйте эту команду.

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

Не забудьте заменить compressed-sqlfile.gz именем сжатого файла.

Восстановление .gz не будет работать без указанной выше команды.

Вы должны решить проблему с файлом dump.sql. Используйте Sequel Pro, проверьте кодировку вашего файла. Это должны быть символы мусора в вашем dump.sql.

У меня была такая же проблема, но я обнаружил, что файл дампа на самом деле был резервной копией сервера MSSQL, а не MySQL.

Иногда устаревшие файлы резервных копий играют с нами злую шутку. Проверьте свой файл дампа.

В окне терминала:

~$ cat mybackup.dmp 

Результат был:

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

Чтобы остановить обработку команды cat:

CTRL + C

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

Файл, который вы пытаетесь импортировать, представляет собой zip-файл. Разархивируйте файл и повторите попытку импорта.

В Linux Разархивируйте файл с помощью gunzip. Отредактируйте распакованный файл sql с помощью

vi unzipsqlfile.sql

Удалите первую двоичную строку с помощью esc dd перейдите в конец файла с помощью esc shift g удалите последнюю двоичную строку с помощью dd сохраните файл esc x: Затем повторно импортируйте в mysql с помощью:

mysql -u имя пользователя -p новая_ база данных <unzipsqlfile.sql

Я выполнил это с помощью sql-файла 20go из резервной копии mysql cpanel jetbackup. Подождите, пока vi выполнит работу для больших файлов

Ваш файл должен иметь только расширение .sql, (.zip, .gz .rar) и т. Д. Не поддерживаются. пример: dump.sql

Вы можете использовать это, чтобы исправить ошибку:

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

Я знаю, что исходный вопрос с плакатами был решен, но я пришел сюда через Google, и различные ответы в конечном итоге привели меня к тому, что я обнаружил, что мой SQL был сброшен с другой кодировкой по умолчанию, чем та, которая использовалась для его импорта. Я получил ту же ошибку, что и исходный вопрос, но, поскольку наш дамп был передан другому клиенту MySQL, мы не могли пойти по пути, открыв его другим инструментом и сохранив по-другому.

Для нас решение оказалось --default-character-set=utf8mb4вариантом, который можно использовать как при вызове, mysqldumpтак и при вызове для импорта через mysql. Конечно, значение параметра может отличаться для других, сталкивающихся с той же проблемой, просто важно сохранить его неизменным, так как для серверов (или инструментов) по умолчанию может использоваться любая кодировка.

Старый но золотой!

На MacOS (Catalina 10.15.7) это было немного странно: мне пришлось переименовать свой dump.sqlв, dump.zipи после этого мне пришлось использовать поисковик (!), Чтобы распаковать его. в терминале unzip dump.zipoder tar xfz dump.sql[or .gz .tar ...]приводит к сообщению об ошибке.

Наконец, Finder полностью разархивировал его, после чего я мог без проблем импортировать файл.