`mysql_upgrade` échoue sans raison réelle donnée
Je passe de MySQL 5.1 à 5.5, exécutant mysql_upgrade et obtenir cette sortie:
# mysql_upgrade
Looking for 'mysql' as: mysql
Looking for 'mysqlcheck' as: mysqlcheck
FATAL ERROR: Upgrade failed
Toutes les idées sur où chercher ce qui se passe (ou ne se produit pas?) Afin que je puisse corriger ce qui ne va pas et exécuter réellement 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 l'arrêt mysqld --skip-grant-tables via mysqladmin shutdown et redémarrer mysql via service mysql start, le journal des erreurs parcourt sans cesse cet ensemble d'erreurs:
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) doivent être corrigés en exécutant mysql_upgrade:
Cette question est incroyablement générique, et je m'en excuse.
Je n'ai pas pu trouver une cause directe et une solution au problème que je rencontrais, j'ai donc recouru à réinstaller MySQL pour voir si cela fonctionnerait. Il s'avère que la réinstallation a fait l'affaire. C'était une façon boiteuse de le réparer, 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 s'exécute initialement, mais pour une raison quelconque - il a échoué car il essayait d'exécuter des requêtes automatisées, et je n'ai pas pu trouver la documentation sur laquelle requêtes qu'il était en cours d'exécution afin que je puisse les corriger.
Je pense qu'il a besoin d'un nom d'utilisateur et d'un mot de passe
mysql_upgrade -u root -p
Si je ne les passe pas, je reçois votre erreur
Edit: grâce aux commentaires maintenant je sais qu'il y a d'autres raisons, peut-être moins fréquentes mais il vaut mieux en être conscient aussi
Vous obtenez donc cette erreur lorsque
- vous n'avez pas transmis votre nom d'utilisateur et votre mot de passe
- vous avez transmis vos informations d'identification, mais elles avaient tort
- le serveur MySQL n'est pas en cours d'exécution
- les tables des permissions sont ruinées (alors vous devez redémarrer MySQL avec
mysqld --skip-grant-table) - la table mysql.plugin est manquante (vous verrez une erreur à ce sujet au démarrage de MySQL qui suggère d'exécuter ... mysql_upgrade, et cela échoue. Vous avez probablement une configuration obsolète dans my.cnf)
Cela semble être un serveur Plesk, lorsque vous utilisez Plesk, il n'y a pas de racine pour Mysql, mais l'administrateur de Mysql a appelé admin, donc cette commande devrait fonctionner sur Plesk comme je l'ai essayé auparavant:
mysql_upgrade -uadmin -p`cat /etc/psa/.psa.shadow`
Je viens de rencontrer ces symptômes précis lors de la mise à niveau de 5.5 vers 5.6, et il s'est avéré que c'était 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 seulement -u et -p fournis, j'avais également besoin de spécifier -h 127.0.0.1 pour mysql_upgrade car il tentait une connexion de fichier socket et échouait lamentablement dans la tentative.
Même problème! La solution pour moi est venue de http://www.freebsd.org/cgi/query-pr.cgi?pr=180624
En bref: l'erreur est trompeuse! courir mysql_upgrade -u root -p avec la base de données en ligne et fournissez le mot de passe root.
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 à niveau 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
de http://dev.mysql.com/doc/refman/5.5/en/mysql-upgrade.html
Vous devez vérifier l'autorisation 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 les données du fichier sans autorisation appropriée. Par exemple, si vos données mysql se trouvent sous/var/lib/mysql
chown -R mysql /var/lib/mysql
Notre DBA a désinstallé la version 5.0.95 de mysql au lieu de simplement mettre à jour vers 5.5.39. La désinstallation a sauvegardé le /etc/my.cnf à /etc/my.cnf.rpmsave l'a ensuite 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 effectuer l'une des opérations suivantes:
Comparez les fichiers my.cnf manuellement et apportez les paramètres de configuration appropriés pour InnoDB
Restaurer le
my.cnf.rpmsaverevenir sur l'original (vérifiez d'abord les nouveaux paramètres par défaut que vous devez ajouter!)Utilisez un outil de comparaison comme
vimdiffpour comparer lemy.cnf.rpmsavevers le nouveaumy.cnfet ramené les modifications apportées à la 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 le mysql_upgrade fonctionne très bien, en utilisant mysql_upgrade -uroot -p donc 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 t'aides!
et en utilisant également mysql_upgrade -uroot -p a échoué car il a besoin de MySQL pour 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.
J'ai eu le même problème lors de la mise à niveau de 5.1 vers 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 du socket, mais je n'ai pas le temps de vérifier que c'était la cause.
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 forcé 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 et ensuite vous pouvez mettre à jour votre mysql.
Dans mon cas, j'avais quelques versions de mysqld fonctionnant localement qui ont fait échouer mysql_upgrade avec Erreur: Échec lors de la récupération de la version du serveur! Cela pourrait être dû à un accès non autorisé.ps aux | grep mysql et assurez-vous que mysqld est bien fermé. Ensuite, désinstallez toutes les versions, réinstallez la bonne version. Et après cela, mysql_upgrade a commencé à fonctionner.
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
ERREUR FATALE: échec de la mise à niveau
C'est assez inutile. --verbose n'a fait aucune différence.
Je me suis installé sur la commande suivante et cela a fonctionné comme un charme:
mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p
J'espère que cela aide.
J'ai fait face à ce problème, et j'ai découvert que,
il fallait que le service MySQL soit en cours d'exécution
il fallait un nom d'utilisateur et un mot de passe
J'ai rencontré le même problème.
J'ai résolu cela en installant une nouvelle base de données par mysql_install_db --user=mysql comme décrit dans les commentaires de mon rc.mysql fichier dans/etc.
Ensuite, j'ai pu démarrer le démon mysql et utiliser 'mysql' ou tout ce que vous voulez connecté avec le paquet mysql.
J'ai eu ce problème sur le bras Slackware, mais supposez que cela n'a pas d'importance dans ce cas.
J'ai également rencontré cela après avoir mis à niveau mon système de Mint 12 à Mint 15. J'avais archivé/var/lib/mysql et l'avais remis en place après la mise à niveau. J'ai exécuté le premier mysqlcheck à partir du commentaire de user16081, et il s'est plaint de mysql.sock.
J'ai commencé mysqld en utilisant /usr/sbin/mysqld & et mysql_upgrade s'est bien passé.