71 votes

LisaG avatar

`mysql_upgrade` échoue sans raison réelle donnée

Demandé el 30 de Juillet, 2013
Quand la question a-t-elle été
127492 affichage
Nombre de visites la question a
5 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Je suis en train de mettre à jour MySQL 5.1 vers 5.5, en exécutant mysql_upgrade et j'obtiens ce résultat :

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

Avez-vous des idées sur la façon de chercher ce qui se passe (ou ne se passe pas ?) afin que je puisse réparer ce qui ne va pas et exécuter réellement le programme ? mysql_upgrade ?

Danke!

Plus de sortie :

# 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

Après l'arrêt de la production mysqld --skip-grant-tables via mysqladmin shutdown et redémarrer mysql via service mysql start le journal des erreurs passe en boucle cet ensemble d'erreurs, encore et encore :

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

Journal MySQL pendant le démarrage via 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)

Si je comprends bien, tous les problèmes de structure/existence des tables (en ce qui concerne les tables système mysql) devraient être corrigés en exécutant mysql_upgrade :

Demandé el 30 de Juillet, 2013 par LisaG

Réponses

Trop de publicités?

3voto

LisaG avatar
LisaG Points 21

Cette question est incroyablement générique, et je m'en excuse.

Je n'ai pas réussi à trouver une cause et une solution directes au problème que je rencontrais, alors j'ai eu recours à la réinstallation de MySQL pour voir si cela pouvait fonctionner. Il s'avère que la réinstallation a fait l'affaire. C'était une façon boiteuse de résoudre le problème, mais c'était la seule option qui me restait.

Beaucoup des autres réponses à cette question sont des problèmes que j'ai dû résoudre pour que mysql_upgrade fonctionne initialement, mais pour une raison quelconque - il a échoué alors qu'il essayait d'exécuter des requêtes automatisées, et je n'ai pas pu trouver la documentation sur les requêtes qu'il exécutait afin de pouvoir les corriger.

Répondu el 30 de Novembre, 2013 par LisaG (21 Points )

3voto

zenekpiwko avatar
zenekpiwko Points 111

Notre DBA a désinstallé la version 5.0.95 de mysql au lieu d'effectuer une simple mise à niveau vers la version 5.5.39. La désinstallation a sauvegardé le /etc/my.cnf zu /etc/my.cnf.rpmsave puis l'a supprimé, ce qui a empêché MySQL de démarrer correctement :

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

Vous pouvez faire l'une des choses suivantes :

  • Comparez manuellement les fichiers my.cnf et ajoutez les paramètres de configuration appropriés pour InnoDB.

  • Rétablir le my.cnf.rpmsave revenir sur l'original (vérifiez d'abord si vous devez ajouter de nouveaux paramètres par défaut !)

  • Utilisez un outil de comparaison comme vimdiff pour comparer les my.cnf.rpmsave au nouveau my.cnf et a repris les modifications qui avaient été apportées à la configuration de MySQL, y compris les paramètres InnoDB.

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

J'ai fait la dernière option, puis j'ai pu démarrer MySQL :

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

et maintenant le mysql_upgrade fonctionne bien, en utilisant mysql_upgrade -uroot -p alors il m'a demandé le mot de passe root.

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

J'espère que cela vous aidera !

et aussi en utilisant mysql_upgrade -uroot -p a échoué car il a besoin que MySQL soit en cours d'exécution !

Les leçons apprises :

  • Sauvegarder my.cnf avant la mise à jour... Et faites réellement une mise à jour sur place au lieu de désinstaller puis d'installer la nouvelle version.
  • Faites fonctionner MySQL pour que vous puissiez utiliser mysql_upgrade.
  • Profit.
Répondu el 2 de Septembre, 2014 par zenekpiwko (111 Points )

2voto

asofyan avatar
asofyan Points 21

Vous devez vérifier la permission de tous les fichiers sous mysql data. Il doit s'agir du même propriétaire du PID mysql (mysql ou _mysql). Cela arrive parfois parce que la restauration des données à partir d'un fichier n'a pas la permission appropriée. Par exemple, si vos données mysql se trouvent sous /var/lib/mysql

chown -R mysql /var/lib/mysql
Répondu el 7 de Novembre, 2013 par asofyan (21 Points )

1voto

Leandro Dardini avatar
Leandro Dardini Points 51

Même problème pour moi, mais la source de mes problèmes était l'ancien format de mot de passe. Alors que mysql peut être forcé à se connecter en utilisant l'ancien format avec "skip-secure-auth", mysql_upgrade n'a pas cette option. Vous devez d'abord mettre à jour le mot de passe root avec le nouveau format et ensuite vous pouvez mettre à jour votre mysql.

Répondu el 21 de Juillet, 2015 par Leandro Dardini (51 Points )

1voto

Capt avatar
Capt Points 11

J'ai eu le même problème en passant de la 5.1 à la 5.5.

Cela a marché pour moi : sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

Mon erreur a probablement été causée par les permissions sur le chemin du socket, mais je n'ai pas eu le temps de vérifier que c'était la cause.

Répondu el 25 de Janvier, 2016 par Capt (11 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X