`mysql_upgrade` échoue sans raison réelle

70

J'effectue une mise à niveau de MySQL 5.1 à la version 5.5, mysql_upgradeet exécute cette sortie:

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

Des idées sur où chercher ce qui se passe (ou ne pas se passer?) Afin que je puisse réparer ce qui ne va pas et courir mysql_upgrade?

Merci!

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 la fermeture mysqld --skip-grant-tablesvia mysqladmin shutdownet le redémarrage de MySQL via service mysql startles boucles journal des erreurs dans cette série d'erreurs encore et:

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 au 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 de table (en ce qui concerne les tables système mysql) devraient être corrigés en lançant mysql_upgrade:

mysql  mysql5.5 
— Jim Rubenstein
source
Aussi probablement rien ne vaut, mysqldest en cours d'exécution, avec --skip-grant-tablesoption. Je peux me connecter via mysqlle terminal sans informations d'identification, et je ne reçois aucune erreur via syslog ou ailleurs, je peux penser à regarder quand je coursmysql_upgrade
— Jim Rubenstein
Le manuel de référence MySQL couvre assez bien la mise à niveau de la version 5.1 à la version 5.5. Si vous avez suivi toutes les instructions ici, il convient de le mentionner. Si vous ne l'avez pas bien fait ...
— Aaron Copley
Si votre utilisateur root mysql n'a pas de mot de passe, n'incluez pas `-p` dans` mysql_upgrade -u root -p`
— Jeferex

Réponses:

95

Je pense qu'il faut un nom d'utilisateur et un mot de passe

mysql_upgrade -u root -p

Si je ne les passe pas, j'obtiens votre erreur

Edit : grâce aux commentaires, je sais maintenant qu’il existe d’autres raisons, peut-être moins fréquentes, mais il vaut mieux les connaître aussi

Donc, vous obtenez cette erreur quand

  • tu n'as pas passé ton nom d'utilisateur et ton mot de passe
  • vous avez passé vos identifiants, mais ils se sont trompés
  • le serveur MySQL n'est pas en cours d'exécution
  • les tables des permissions sont ruinées (vous devez ensuite redémarrer MySQL avec mysqld --skip-grant-table)
  • la table mysql.plugin est manquante (vous verrez une erreur à ce sujet lors du démarrage de MySQL qui suggère de lancer ... mysql_upgrade, et cela échoue. Vous avez probablement une configuration obsolète dans my.cnf)
— Riccardo Galli
source
23
C’était exactement le problème que j’avais: pourquoi diable ne pouvait-il pas simplement dire "Impossible de s’authentifier" ou "Erreur de connexion" ou quelque chose du genre? Tellement en colère ...
— les2
3
Les gars, vous obtenez la même erreur si votre mot de passe est également faux. alors soyez informé.
— Yoosaf Abdulla
3
Et vous obtenez la même erreur si le serveur n'est pas en cours d'exécution, même s'il semble accepter le mot de passe.
— Raman
1
juste quand la table de base de données ou le format de base de données est également cassé, cela ne fonctionne pas non plus, alors vous devez démarrer le démon avec "mysqld --skip-grant-tables" et exécuter mysql_upgrade dans un autre terminal!
— Henning
+1 pour cela. Encore une autre raison pour laquelle je déteste MySQL
— Excalibur
9

Je viens de rencontrer ces symptômes précis lors de la mise à niveau de la version 5.5 à la version 5.6 et il s’est avéré qu’il s’agissait d’un problème d’accessibilité au service.

Même si le client cli MySQL pouvait se connecter à mon instance de base de données locale avec uniquement les options -u et -p fournies, je devais également spécifier -h 127.0.0.1 pour mysql_upgrade car il tentait une connexion de fichier de socket et échouait lamentablement dans cette tentative.

— Aubrey Falconer
source
c'était exactement mon problème parce que je lance mysqd comme ceci: mysqld --skip-grant-tables --user = mysql
— Rodo
9

Cela semble être un serveur Plesk. Lorsque Plesk est utilisé, il n’existe aucune racine pour Mysql, mais l’administrateur de Mysql a appelé admin. Cette commande devrait donc fonctionner sur Plesk, comme je l’avais déjà essayé:

mysql_upgrade -uadmin -p`cat /etc/psa/.psa.shadow`
— linuxman1
source
Cela a fonctionné parfaitement pour moi
— xarlymg89
5

vous pouvez essayer de les exécuter un par un pour voir où cela échoue:

mysql_upgrade exécute les commandes suivantes pour vérifier et réparer les tables et pour mettre à jour les tables système: 

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

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

— utilisateur16081-JoeT
source
1
Pensée à ce sujet, mais fix_priv_tablesest un script qui est généré par mysql_upgradeafin de corriger les tables de privilèges
— Jim Rubenstein
bon point, peut-être essayer juste la première ligne mysqlcheck? Et essayez de courir à partir du dossier bin directement, fwiw,/usr/bin/mysql_upgrade
— user16081-JoeT
3

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

Je ne pouvais pas trouver une cause directe et une solution au problème que je rencontrais. J'ai donc réinstallé MySQL pour voir si cela fonctionnerait. Il s'avère que réinstaller a fait l'affaire. C’était une mauvaise façon de régler le problème, mais c’était la seule option qui me restait.

Beaucoup d'autres réponses à cette question sont des problèmes que j'ai dû résoudre pour que mysql_upgrade soit exécuté au départ, mais pour une raison quelconque - cela a échoué car il essayait d'exécuter des requêtes automatisées, et je ne trouvais pas la documentation sur laquelle requêtes qu'il courait afin que je puisse les réparer.

— Jim Rubenstein
source
Oui, une fois que le répertoire de données de mysql a été corrompu, vous ne pouvez pratiquement plus rien faire
— Krauser
2

Vous devez vérifier l'autorisation de tous les fichiers sous les données mysql. Il devrait être le même propriétaire de mysql PID (mysql ou _mysql). Cela se produit parfois parce que restaurer des données à partir d'un fichier sans la permission appropriée. Par exemple, si vos données mysql sont sous / var / lib / mysql

chown -R mysql /var/lib/mysql
— asofyan
source
2

Notre administrateur de base de données a désinstallé la version 5.0.95 de MySQL au lieu de simplement passer à la version 5.5.39. La désinstallation sauvegardée la /etc/my.cnfpour /etc/my.cnf.rpmsaveensuite retiré, et cela 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 effectuer l'une des opérations suivantes:

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

  • Restaurez le my.cnf.rpmsaveretour sur l'original (vérifiez d'abord si de nouveaux paramètres par défaut doivent être ajoutés!)

  • Utilisez un outil de diff comme vimdiffpour comparer les my.cnf.rpmsaveau nouveau my.cnfet ramené sur les tweaks qui avaient été faites à configuration 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 les mysql_upgradefonctionne très bien, en utilisant mysql_upgrade -uroot -pdonc il m'a invité à entrer 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 t'aides!

et aussi utiliser a mysql_upgrade -uroot -péchoué car MySQL doit fonctionner!

Leçons apprises:

  • Sauvegardez my.cnf avant la mise à niveau ... Et effectuez une mise à niveau sur place au lieu de désinstaller puis d'installer la version la plus récente.
  • Lancez MySQL pour pouvoir utiliser mysql_upgrade.
  • Profit.
— Ronnie
source
1

Même problème pour moi, mais la source de mes problèmes était l'ancien format de mot de passe. Bien que mysql puisse être obligé de 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, puis vous pourrez mettre à jour votre mysql.

— Leandro Dardini
source
1

Avait le même problème de mise à niveau de 5.1 à 5.5.

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

Mon erreur a probablement été causée par des autorisations sur le chemin d'accès au socket, mais je n'ai pas le temps de vérifier si c'est bien la cause.

— Capt
source
J'avais déplacé mon DataDir à un moment donné, je suppose que c'est pourquoi j'avais besoin du chemin d'accès au socket
— zzapper
0

Je viens juste de le rencontrer également après la mise à niveau de mon système de Mint 12 à Mint 15. J'avais archivé / var / lib / mysql et je l'avais remis en place après la mise à niveau. J'ai couru le premier à mysqlcheckpartir du commentaire de user16081, et il s'est plaint de mysql.sock.

J'ai commencé à utiliser mysqld /usr/sbin/mysqld &et j'ai mysql_upgradebien fonctionné.

— Marty Vance
source
C'est une méthode assez effrayante pour mettre à jour MySQL, mais je suis heureux que cela ait fonctionné pour vous.
— Aaron Copley
@ aaron-copley: en réalité, cela n'a pas complètement fonctionné. MySQL 5.5.32 ignore partiellement beaucoup de mes tables InnoDB; ils apparaissent dans SHOW TABLES, mais sinon n'existent pas. J'essaie actuellement de faire fonctionner les utilitaires mysql, mais c'est pour me plaindre de l'absence de modules python.
— Marty Vance
0

J'ai rencontré le même problème.
Je l'ai résolu en incluant le -S /path/to/mysql.sock

Dans mon cas particulier, la sortie de mysql_upgrade était:
Recherche de 'mysql' comme: mysql
Recherche de 'mysqlcheck' comme: mysqlcheck
FATAL ERROR: La mise à niveau a échoué.

C'est plutôt inutile. --verbose ne fait aucune différence.

En me
connectant, j'ai choisi la commande suivante et cela a fonctionné à merveille: mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

J'espère que ça aide.

— bfieber
source
0

J'ai fait face à ce problème et j'ai découvert que

  1. le service MySQL devait être en cours d'exécution

  2. il fallait un nom d'utilisateur et un mot de passe

— Sruit A.Suk
source
0

J'ai rencontré le même problème.

J'ai résolu ce problème en installant une nouvelle base de données mysql_install_db --user=mysqlcomme décrit dans les commentaires de mon rc.mysqlfichier dans / etc.

Ensuite, j'ai pu démarrer le démon mysql et utiliser «mysql» ou ce que vous voulez connecter avec le paquet mysql.

J'ai eu ce problème sur le bras slackware, mais supposons que ce ne soit pas grave dans ce cas.

— utilisateur323106
source
0

Dans mon cas, quelques versions de mysqld s'exécutant localement ont provoqué l'échec de mysql_upgrade avec Erreur: Echec lors de la récupération de la version du serveur! Peut être dû à un accès non autorisé. ps aux | grep mysqlet assurez-vous que mysqld est tout éteint. Ensuite, désinstallez toutes les versions, réinstallez la bonne version. Et après cela, mysql_upgrade a commencé à fonctionner.

— Laurens Bronwasser
source
-1

essayer 

mysql_upgrade --verbose

ou peut-être même (ou les deux)

--debug-check --debug-info
— alexus
source
Essayé ceux-ci, aucune information vraiment utile, je ne pense pas |;
— Jim Rubenstein
redémarré et collé des informations du journal des erreurs \; Je ne sais pas pourquoi il continuerait à répéter sans cesse ces mêmes erreurs.
— Jim Rubenstein
il semble que vous ayez une erreur là-bas - 130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't existje pense que c’est ce qui fait que tout échoue.
— Alexus
mais avant cela, essayez mysql_upgrade --version et fournissez un résultat pour cela.
— alexus
mysql_upgrade --versionne produit pas de version (uniquement l'erreur FATAL ERROR). mysql --versionmysql Ver 14.14 Distrib 5.5.32, pour debian-linux-gnu (x86_64) utilisant readline 6.2, et la version de mysqld est 5.5
— Jim Rubenstein
-3

L'utilisateur root de MySQL s'appelle "admin", pas root. La bonne commande est

mysql_upgrade -uadmin -p
— Marco Marsala
source
C'est absolument faux. L'utilisateur root dans MySQL est root.
— dr01
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.