mysql_upgrade не работает без указания реальной причины

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

mysql_upgrade -u root -p

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

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

Итак, вы получите эту ошибку, когда

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

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

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

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

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

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

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

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

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

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

Я не смог найти прямую причину и решение возникшей у меня проблемы, поэтому прибег к повторной установке 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.
• Прибыль.

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

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

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

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

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

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

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

Затем я смог запустить демон mysql и использовать mysql или что угодно, связанное с пакетом mysql.

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

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

1. требовалось, чтобы служба MySQL работала

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

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

В моем конкретном случае вывод mysql_upgrade был:
Ищем mysql как: mysql
Ищем mysqlcheck как: mysqlcheck
ФАТИЧЕСКАЯ ОШИБКА: не удалось выполнить обновление.

Это бесполезно. --verbose не имело значения.

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

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

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

Я запустил mysqld, используя /usr/sbin/mysqld & и mysql_upgrade работал нормально.

пытаться

mysql_upgrade --verbose 

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

--debug-check --debug-info

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

mysql_upgrade -uadmin -p