mysql_upgrade не работает без объяснения причин

Я обновляю с MySQL 5.1 до 5.5, работаю mysql_upgradeи получаю этот вывод:

# mysql_upgrade
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

Любые идеи о том, где искать то, что происходит (или не происходит?), Чтобы я мог исправить все, что не так, и на самом деле запустить mysql_upgrade?

Спасибо!

Больше выхода:

# mysql_upgrade --verbose
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

# mysql_upgrade --debug-check --debug-info
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

# mysql_upgrade --debug-info
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

User time 0.00, System time 0.00
Maximum resident set size 1260, Integral resident set size 0
Non-physical pagefaults 447, Physical pagefaults 0, Swaps 0
Blocks in 0 out 16, Messages in 0 out 0, Signals 0
Voluntary context switches 9, Involuntary context switches 5

# mysql_upgrade --debug-check
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed

После завершения mysqld --skip-grant-tablesчерез mysqladmin shutdownи повторного запуска mysql через service mysql startжурнал ошибок снова и снова повторяется этот набор ошибок:

130730 21:03:27 [Note] Plugin 'FEDERATED' is disabled.
/usr/sbin/mysqld: Table 'mysql.plugin' doesn't exist
130730 21:03:27 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
130730 21:03:27 InnoDB: The InnoDB memory heap is disabled
130730 21:03:27 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130730 21:03:27 InnoDB: Compressed tables use zlib 1.2.3.4
130730 21:03:27 InnoDB: Initializing buffer pool, size = 20.0G
130730 21:03:29 InnoDB: Completed initialization of buffer pool
130730 21:03:30 InnoDB: highest supported file format is Barracuda.
InnoDB: Log scan progressed past the checkpoint lsn 588190222435
130730 21:03:30  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 588192055067
130730 21:03:30  InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 81298895, file name /var/log/mysql/mysql-bin.006008
130730 21:03:33  InnoDB: Waiting for the background threads to start
130730 21:03:34 InnoDB: 5.5.32 started; log sequence number 588192055067
130730 21:03:34 [Note] Recovering after a crash using /var/log/mysql/mysql-bin
130730 21:03:34 [Note] Starting crash recovery...
130730 21:03:34 [Note] Crash recovery finished.
130730 21:03:34 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
130730 21:03:34 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
130730 21:03:34 [Note] Server socket created on IP: '0.0.0.0'.
130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist

Журнал MySQL во время запуска через mysqld_safe --skip-grant-tables

130730 21:19:36 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
130730 21:19:36 [Note] Plugin 'FEDERATED' is disabled.
130730 21:19:36 InnoDB: The InnoDB memory heap is disabled
130730 21:19:36 InnoDB: Mutexes and rw_locks use GCC atomic builtins
130730 21:19:36 InnoDB: Compressed tables use zlib 1.2.3.4
130730 21:19:37 InnoDB: Initializing buffer pool, size = 20.0G
130730 21:19:39 InnoDB: Completed initialization of buffer pool
130730 21:19:39 InnoDB: highest supported file format is Barracuda.
130730 21:19:42  InnoDB: Warning: allocated tablespace 566, old maximum was 0
130730 21:19:42  InnoDB: Waiting for the background threads to start
130730 21:19:43 InnoDB: 5.5.32 started; log sequence number 588192055067
130730 21:19:43 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
130730 21:19:43 [Note]   - '0.0.0.0' resolves to '0.0.0.0';
130730 21:19:43 [Note] Server socket created on IP: '0.0.0.0'.
130730 21:19:43 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
130730 21:19:43 [ERROR] Can't open and lock privilege tables: Table 'mysql.servers' doesn't exist
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_current' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_history' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_history_long' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'setup_consumers' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'setup_instruments' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'setup_timers' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'performance_timers' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'threads' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_thread_by_event_name' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_summary_by_instance' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'events_waits_summary_global_by_event_name' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'file_summary_by_event_name' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'file_summary_by_instance' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'mutex_instances' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'rwlock_instances' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'cond_instances' has the wrong structure
130730 21:19:43 [ERROR] Native table 'performance_schema'.'file_instances' has the wrong structure
130730 21:19:43 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.32-0ubuntu0.12.04.1-log'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Ubuntu)

Насколько я понимаю, все проблемы со структурой / существованием таблиц (в том, что касается системных таблиц mysql) должны быть исправлены с помощью команды mysql_upgrade:

Я думаю, что для этого нужно имя пользователя и пароль

mysql_upgrade -u root -p

Если я не передам их, я получу вашу ошибку

Изменить : благодаря комментариям теперь я знаю, что есть и другие причины, возможно, менее частые, но лучше знать о них тоже

Таким образом, вы получаете эту ошибку, когда

• Вы не передали имя пользователя и пароль
• вы передали свои полномочия, но они были не правы
• сервер MySQL не работает
• таблицы разрешений разрушены (тогда вы должны перезапустить MySQL с помощью mysqld --skip-grant-table)
• таблица mysql.plugin отсутствует (вы увидите ошибку об этом при запуске MySQL, которая предлагает выполнить ... mysql_upgrade, и это не удается. Возможно, у вас есть устаревшая конфигурация в my.cnf)

Я только что столкнулся с этими точными симптомами при обновлении с 5.5 до 5.6, и это оказалось проблемой доступности сервиса.

Несмотря на то, что клиент MySQL cli мог подключаться к моему локальному экземпляру БД, используя только -u и -p, мне также нужно было указать -h 127.0.0.1 для mysql_upgrade, так как он пытался подключиться к файлу сокета и потерпел неудачу при попытке.

Это кажется сервером Plesk, при использовании Plesk для Mysql нет рута, но администратор Mysql вызвал admin, поэтому эта команда должна работать на Plesk, как я пробовал раньше:

mysql_upgrade -uadmin -p`cat /etc/psa/.psa.shadow`

Вы можете попробовать запустить их один за другим, чтобы увидеть, где это не получается:

mysql_upgrade выполняет следующие команды для проверки и исправления таблиц и обновления системных таблиц:

mysqlcheck --all-databases --check-upgrade --auto-repair  
mysql < fix_priv_tables  
mysqlcheck --all-databases --check-upgrade --fix-db-names --fix-table-names

с http://dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html

Та же проблема! Решение для меня пришло от http://www.freebsd.org/cgi/query-pr.cgi?pr=180624

Вкратце: ошибка вводит в заблуждение! запустить mysql_upgrade -u root -pс БД в режиме онлайн и предоставить пароль root.

Этот вопрос невероятно общий, и я прошу прощения за это.

Я не мог найти прямую причину и решение проблемы, с которой столкнулся, поэтому прибегнул к переустановке MySQL, чтобы посмотреть, сработает ли это. Оказывается, переустановка сделала свое дело. Это был слабый способ исправить это, но это был единственный вариант, который я оставил.

Многие другие ответы на этот вопрос - проблемы, с которыми мне пришлось столкнуться, чтобы сначала запустить mysql_upgrade, но по какой-то причине - не удалось, так как он пытался выполнить некоторые автоматические запросы, и я не смог найти документацию, по которой запросы он выполнялся, чтобы я мог их исправить.

Вы должны проверить разрешение всех файлов под данными MySQL. Это должен быть тот же владелец mysql PID (mysql или _mysql). Это иногда происходит, потому что восстановить данные из файла без надлежащего разрешения. Например, если ваши данные mysql находятся в / var / lib / mysql

chown -R mysql /var/lib/mysql

Наш администратор баз данных удалил MySQL версии 5.0.95 вместо обновления до 5.5.39. Деинсталлировать резервное копирование , /etc/my.cnfчтобы /etc/my.cnf.rpmsaveзатем удалить его, и это не позволяло MySQL от запуска правильно:

140902 15:00:57 [ERROR] Plugin 'InnoDB' init function returned error.
140902 15:00:57 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140902 15:00:57 [ERROR] Unknown/unsupported storage engine: InnoDB
140902 15:00:57 [ERROR] Aborting

Вы можете сделать любое из следующего:

• Сравните файлы my.cnf вручную и приведите соответствующие параметры конфигурации для InnoDB

• Восстановите my.cnf.rpmsaveобратно поверх оригинала (сначала проверьте наличие новых настроек по умолчанию, которые вы должны добавить!)

• Используйте инструмент сравнения, например, vimdiffдля сравнения с my.cnf.rpmsaveновым my.cnfи вернул настройки, которые были внесены в конфигурацию MySQL, включая настройки InnoDB.

  [root]# vimdiff /etc/my.cnf /etc/my.cnf.rpmsave

Я сделал последний вариант, затем смог запустить MySQL:

root]# service mysqld start
Starting mysqld:                                           [  OK  ]

и теперь mysql_upgradeработает нормально, используя mysql_upgrade -uroot -pтак, что мне предложили ввести пароль root.

[root]# mysql_upgrade -uroot -p
Enter password:
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
Running 'mysqlcheck with default connection arguments
....

Надеюсь это поможет!

а также использование mysql_upgrade -uroot -pне удалось, потому что для этого требуется MySQL!

Уроки выучены:

• Сделайте резервную копию my.cnf перед обновлением ... И на самом деле вместо обновления удалите обновление на месте, а затем установите более новую версию.
• Запустите MySQL, чтобы вы могли использовать mysql_upgrade.
• Прибыль.

Та же проблема для меня, но источником моих проблем был старый формат пароля. Хотя mysql может быть принудительно подключен с использованием старого формата с помощью «skip-secure-auth», mysql_upgrade не имеет этой опции. Сначала вам нужно обновить пароль root с новым форматом, а затем вы можете обновить свой mysql.

Была такая же проблема при обновлении с 5.1 до 5.5.

Это сработало для меня: sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

Моя ошибка, вероятно, была вызвана разрешениями на путь к сокету, но у меня не было времени, чтобы проверить, что это было причиной.

Я также столкнулся с этим после обновления моей системы с Mint 12 до Mint 15. Я заархивировал / var / lib / mysql и вернул его на место после обновления. Я запустил первый mysqlcheckиз комментария user16081, и он пожаловался на mysql.sock.

Я начал использовать MySQL /usr/sbin/mysqld &и mysql_upgradeработал нормально.

Я столкнулся с той же проблемой.
Я решил это, включив -S /path/to/mysql.sock

В моем конкретном случае вывод mysql_upgrade был следующим: «
Поиск mysql» как: mysql
Поиск «mysqlcheck» как: mysqlcheck
FATAL ERROR: Обновление не удалось

Это довольно бесполезно. - Вербус не имеет значения.

Подключившись, я остановился на следующей команде, и она работала как
чудо : mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

Надеюсь, это поможет.

Я столкнулся с этой проблемой, и я узнал, что

1. это требовало, чтобы MySQL Service был запущен

2. требуется имя пользователя и пароль

Я столкнулся с той же проблемой.

Я решил эту проблему, установив новую базу данных, mysql_install_db --user=mysqlкак описано в комментариях к моему rc.mysqlфайлу в / etc.

Затем я смог запустить демон MySQL и использовать «MySQL» или что-то еще, что вы хотите, связанные с пакетом MySQL.

У меня была эта проблема на руке Slackware, но, возможно, это не имеет значения в этом случае.

В моем случае у меня было несколько версий mysqld, работающих локально, что приводило к сбою mysql_upgrade с ошибкой: ошибка при загрузке версии сервера! Может быть из-за несанкционированного доступа. ps aux | grep mysqlи убедитесь, что mysqld все выключен. Затем Brew удалить все версии, переустановите нужную версию. И после этого mysql_upgrade начал работать.

пытаться

mysql_upgrade --verbose 

или, может быть, даже (или оба)

--debug-check --debug-info

Пользователь root для MySQL называется «admin», а не root. Правильная команда

mysql_upgrade -uadmin -p