При импорте базы данных через mysql клиент примерно следующим образом:
mysql -uroot < z:\all-databases.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: ' ■-'.
В ней сказано, что появился символ, который стал неожиданностью для СУБД. Подразумевался текстовый файл, а программа столкнулась с символами, характерными для бинарного файла. Поэтому она нас советует — что если это действительно бинарный файл, то нужно установить соответствующий режим с помощью опции --binary-mode.
Обычно дамп базы данных НЕ является бинарным файлом, поэтому опция --binary-mode будет неуместной в данном случае. Необходимо найти настоящую причину проблемы.
Во-первых, убедитесь, что вы по ошибке не импортируете архив. То есть если вы поместили дамп базы данных в архив, не забудьте перед восстановлением базы данных извлечь её из этого архива.
Вторая причина может быть в кодировке файла дампа. Как мы можем видеть, MySQL предполагает, что это файл в ASCII кодировке.
С помощью команды file можно проверить, какая именно это кодировка. Например, у меня файл расположен по пути /mnt/disk_d/Share/all-databases.sql, проверяю его:
file '/mnt/disk_d/Share/all-databases.sql'
В моём случае выведено:
/mnt/disk_d/Share/all-databases.sql: Little-endian UTF-16 Unicode text, with very long lines, with CRLF line terminators
То есть это UTF-16 с очень длинными строками.
Чтобы исправить проблему в данном случае, конвертируйте файл в UTF-8 с помощью iconv командой вида:
iconv -f utf-16 -t utf-8 ИСХОДНЫЙ_ФАЙЛ.sql > НОВЫЙ_ФАЙЛ_utf8.sql
Реальный пример в моей ситуации:
iconv -f utf-16 -t utf-8 '/mnt/disk_d/Share/all-databases.sql' > '/mnt/disk_d/Share/all-databases_utf8.sql'
После этого я успешно смог импортировать новый файл all-databases_utf8.sql для восстановления базы данных:
mysql -uroot < z:\all-databases_utf8.sql
Такая ситуация у меня возникла когда я файл дампа, созданный в Windows, хранил в Linux. Затем в Linux же я его распаковал и вернул в Windows для восстановления. Также есть сообщение, что другой пользователь столкнулся с этой же ошибкой при переносе файла из Windows в Mac. То есть причиной неправильного определения кодировки может стать подготовка дампа в одной операционной системе и импорт в другой. Для решения этой проблемы достаточно конвертировать кодировку показанным выше способом.
Чтобы правильно определить исходную кодировку файла, смотрите статью «Как определить кодировку файла или строки. Как конвертировать файлы в кодировку UTF-8 в Linux».
P.S.
У меня на скриншоте новая ошибка:
ERROR 3554 (HY000) at line 24230: Access to data dictionary table 'mysql.index_stats' is rejected.
Это какая-то новая «фича» MySQL 8.0 с которой ещё предстоит разобраться...
Связанные статьи:
- Ошибка «ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/run/mysqld/mysqld.sock' (2 "No such file or directory")» (РЕШЕНО) (100%)
- Ошибка «Unknown/unsupported storage engine: InnoDB» (РЕШЕНО) (100%)
- Ошибка «mysqli_connect(): (HY000/1045): Access denied for user 'username'@'localhost'» (РЕШЕНО) (100%)
- Ошибка «Failed - Network error» во время экспорта в phpMyAdmin (РЕШЕНО) (100%)
- Ошибка «ERROR 1044 (42000): Access denied for user 'mial'@'localhost' to database 'TestDB'». Не удаётся создать базу данных MySQL (РЕШЕНО) (100%)
- Ошибка «PHP Fatal error: Uncaught mysqli_sql_exception: No database selected» (РЕШЕНО) (RANDOM - 100%)