Помилка під час відновлення бази даних з дампа 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, наприклад) d потрібно видалити його, перш ніж вставляти його 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: утиліта "файл" - це інструмент від 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's створює закодований файл UTF-16, який викликає проблеми. Шукайте Powershell тут: dev.mysql.com/doc/refman/5.7/uk/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, але продавець знаходиться на рівні 4,0, а мої початкові виправлення не працюють у старих версіях PowerShell.

Потрібно використовувати | Set-Content -Encoding UTF8 $fileName

Це вже запропонував Іфєді


0

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

Дивіться: /programming/7256049/notepad-converting-ansi-encoded-file-to-utf-8

Іншим варіантом може бути використання textwrangle для відкриття та збереження файлу як UTF-8: http://www.barebones.com/products/textwrangler/


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

І RESTORE вилучив файл dump.sql.

Ref: Про бінарний та інтерактивний режим MySQL.

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

Це працює для мене і все встановлено !!


0

У моєму випадку файл був пошкоджений. Базу даних стискали з розширенням.bz2 але насправді це було a .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.