Увімкніть двійковий режим під час відновлення бази даних із дампа 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-modeвставити файл ini, але він все одно видає ту ж помилку. Що я повинен зробити? Будь ласка, допоможіть.

ОНОВЛЕННЯ

Як запропонував Нік у своєму коментарі, я спробував, $ > 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, і існує версія вікна тут .
Результатом мого файлу дампа є:

Мало-ендіанський текст UTF-16 Unicode, з дуже довгими рядками, з термінаторами рядків 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

Ви пробували відкрити в notepad ++ (або іншому редакторі) і перетворити / зберегти нас на 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 new_database <unzipsqlfile.sql

Я виконав це за допомогою файлу 20go sql із резервної копії jetbackup cpanel mysql. Будьте терплячі чекати 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а після цього мені довелося використовувати finder (!), Щоб розпакувати його. в терміналі unzip dump.zipoder tar xfz dump.sql[or .gz .tar ...]призводить до повідомлень про помилки.

Нарешті, finder повністю розпакував його, після цього я міг імпортувати файл без проблем.