Вопрос: `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 :


68
2017-07-30 20:21


Источник


Также, вероятно, ничего не стоит, mysqld работает, с --skip-grant-tables вариант. Я могу подключиться через mysql на терминале без учетных данных, и я не получаю ошибок через syslog или где-либо еще, что я могу думать, когда я запускаю mysql_upgrade - Jim Rubenstein
Справочное руководство по MySQL улучшает до 5,5 от 5.1 довольно хорошо. Если вы следовали всем инструкциям здесь, стоит упомянуть. Если вы этого не сделали, хорошо ... - Aaron Copley
Если ваш пользователь root mysql не имеет пароля, не включайте `-p` в` mysql_upgrade -u root -p` - Jeferex


Ответы:


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

mysql_upgrade -u root -p

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

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

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

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

92
2017-08-14 10:01



Это была именно та проблема, с которой я столкнулся - почему, черт возьми, он не мог просто сказать «Не удалось аутентифицировать» или «Ошибка подключения» или что-то еще? Так зол ... - les2
Ребята, вы получите ту же ошибку, если ваш пароль тоже не так. так что имейте в виду. - Yoosaf Abdulla
И вы получите ту же ошибку, если сервер не запущен, даже если он принимает пароль. - Raman
просто когда таблица базы данных или формат базы данных тоже сломаны, она тоже не работает, тогда вам нужно запустить демон с «mysqld -skip-grant-tables» и запустить mysql_upgrade в другом терминале! - Henning
+1 для этого. Еще одна причина, по которой я ненавижу MySQL - Excalibur


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

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


9
2017-08-19 19:33



это была именно моя проблема, потому что я запускаю mysqd следующим образом: mysqld --skip-grant-tables --user = mysql - Rodo


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

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

9
2017-10-09 08:56



Это отлично сработало для меня - Carlos Alberto Martínez Gadea


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

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


4
2017-07-30 21:10



Мысль об этом, но fix_priv_tables это скрипт, который генерируется mysql_upgrade для того, чтобы фиксировать таблицы приоритетов - Jim Rubenstein
хорошая точка, возможно, попробуйте только первую строку mysqlcheck? И попробуйте запустить из папки bin напрямую, fwiw, /usr/bin/mysql_upgrade - user16081-JoeT


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

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


4
2017-11-30 10:23





Этот вопрос невероятно важен, и я извиняюсь за это.

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

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


3
2017-11-30 14:00



Да, когда данные dir mysql были повреждены, вы почти ничего не можете сделать - Krauser


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

chown -R mysql /var/lib/mysql

2
2017-11-07 00:12