"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 міг підключитися до мого локального екземпляра БД лише за умови надання -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/uk/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

Наша DBA видалила 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 не має цієї опції. Спочатку потрібно оновити корінний пароль новим форматом, а потім можна оновити свій mysql.

З такою ж проблемою було оновлено 5,1 до 5,5.

Це працювало для мене: sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

Моя помилка, ймовірно, була викликана дозволами на шлях сокета, але не встигли переконатися, що це причина.

Я просто наткнувся на це також після оновлення моєї системи з монетного двору 12 до монетного двору 15. У мене був архівований / var / lib / mysql і повернути його на місце після оновлення. Я побіг першим mysqlcheckіз коментаря user16081, і він скаржився на mysql.sock.

Я почав використовувати mysqld /usr/sbin/mysqld &і mysql_upgradeчудово побіг.

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

У моєму конкретному випадку результат mysql_upgrade був:
Шукаю 'mysql' як: mysql
Шукаю 'mysqlcheck' як: mysqlcheck
FATAL ERROR: Оновлення не вдалося

Це досить марно. --verbose не змінився.

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

Сподіваюся, це допомагає.

Я зіткнувся з цією проблемою, і я дізнався, що

1. для цього потрібна служба MySQL

2. для цього потрібні ім’я користувача та пароль

Я зіткнувся з тим же питанням.

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

Тоді я зміг запустити mysql демон і використовувати "mysql" або все, що завгодно, пов'язане з пакунком mysql.

Я мав цю проблему в рукоятці програмного забезпечення, але припустимо, що це не має значення в цьому випадку.

У моєму випадку у мене було кілька версій mysqld, які працюють локально, які зробили збій mysql_upgrade з помилкою: Помилка під час отримання версії сервера! Це може бути пов’язано з несанкціонованим доступом. ps aux | grep mysqlі переконайтесь, що mysqld закритий. Потім заваріть видалення всієї версії, перевстановіть правильну версію. А після цього mysql_upgrade почав працювати.

спробуйте

mysql_upgrade --verbose 

а може навіть (або обидва)

--debug-check --debug-info

Користувач root для MySQL має ім'я "admin", а не root. Правильна команда

mysql_upgrade -uadmin -p