我正在从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并通过service mysql start重新启动mysql后，错误日志循环遍历这组错误及以上：

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


通过mysqld_safe --skip-grant-tables启动时的MySQL日志

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来纠正：

评论

也可能一文不值，mysqld正在运行，带有--skip-grant-tables选项。我可以在没有凭据的情况下通过mysql在终端上进行连接，并且通过syslog或运行mysql_upgrade
时可以看到的其他任何地方都不会出现错误。
MySQL参考手册涵盖了从5.1到5.5的升级。如果您按照此处的所有说明进行操作，那么值得一提。如果还没有，那么...
如果您的mysql root用户没有密码，则不要在mysql_upgrade -u root -p中包含`-p'

#1 楼

我认为它需要用户名和密码

mysql_upgrade -u root -p


如果我不通过它们，我会收到您的错误

编辑：感谢评论现在我知道还有其他原因，也许不那么频繁，但是最好也要注意这些原因。
所以当您


t传递用户名和密码
您传递了凭据，但密码不正确
MySQL服务器未运行
权限表被破坏（然后您必须使用mysqld --skip-grant-table重新启动MySQL）
表mysql.plugin丢失（启动MySQL时会提示运行mysql_upgrade的错误，并且失败。您可能在my.cnf中有一些过时的配置）


评论

这正是我遇到的问题-为什么不能说“无法验证”或“连接错误”之类的内容？太生气了 ...

–les2
2013年9月30日20:26在
伙计们，如果您的密码也错误的话，也会遇到同样的错误。所以被告知。

–约萨夫·阿卜杜拉（Yoosaf Abdulla）
2013年12月4日15:25
如果服务器未运行，即使它似乎接受密码，您也会收到相同的错误。

–拉曼
2013年12月19日下午3:25
只是当数据库表或数据库格式也损坏时，它也不起作用，那么您需要使用“ mysqld --skip-grant-tables”启动守护进程，并在另一个终端上运行mysql_upgrade！

–亨宁
2014年5月5日14:52


为此+1。我讨厌MySQL的另一个原因

–神剑
2014年10月8日19:33

#2 楼

从5.5升级到5.6时，我只是遇到了这些确切的症状，事实证明这是服务可达性问题。

即使cli MySQL客户端只能通过-u连接到我的本地数据库实例和-p提供，我还需要为mysql_upgrade指定-h 127.0.0.1，因为它正在尝试建立套接字文件连接并且尝试失败。

评论

那正是我的问题，因为我这样运行mysqd：mysqld --skip-grant-tables --user = mysql

–罗多
2014年2月13日在13:28


#3 楼

这似乎是一个Plesk服务器，使用Plesk时Mysql没有根目录，但是Mysql的管理员称为admin，因此该命令应该在Plesk上正常工作，就像我之前尝试过的那样：

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


评论

这对我来说很完美

–xarlymg89
16年4月4日在9:53

#4 楼

您可以尝试逐个运行这些命令以查看失败的地方：


mysql_upgrade执行以下命令来检查和修复表并升级系统表：


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


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

评论

考虑了一下，但是fix_priv_tables是由mysql_upgrade生成的脚本，用于修复privelege表

–吉姆·鲁宾斯坦（Jim Rubenstein）
13年7月30日在21:12
好点，也许只是尝试第一个mysqlcheck行？并尝试直接从bin文件夹fwiw运行/ usr / bin / mysql_upgrade

–user16081-JoeT
13年7月30日在21:15


#5 楼

同样的问题！对我来说，解决方案来自http://www.freebsd.org/cgi/query-pr.cgi?pr=180624

简而言之：该错误具有误导性！使用DB在线运行mysql_upgrade -u root -p并提供root密码。

#6 楼

这个问题是非常普遍的，对此我深表歉意。

我找不到我所遇到问题的直接原因和解决方案，所以我求助于重新安装MySQL以查看是否会那样工作。原来，重新安装确实成功了。那是修复它的la脚方式，但这是我唯一的选择。

关于此问题的许多其他答案是我必须解决的问题才能使mysql_upgrade最初运行，但是由于某种原因-它由于尝试运行一些自动查询而失败，并且我找不到正在运行查询的文档，因此可以对其进行修复。

评论

是的，一旦mysql的数据目录已损坏，您几乎无能为力

–斯蒂芬
16-09-27在13:36

#7 楼

您必须检查权限mysql数据下的所有文件。它应该是mysql PID的相同所有者（mysql或_mysql）。之所以会发生这种情况，是因为未经适当许可从文件还原数据。例如，如果您的mysql数据位于/ var / lib / mysql 

chown -R mysql /var/lib/mysql


#8 楼

我们的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。
Profit。


#9 楼

对我来说同样的问题，但问题的根源是旧的密码格式。虽然可以使用“ skip-secure-auth”的旧格式来强制mysql连接，但mysql_upgrade没有此选项。您需要首先以新格式更新root密码，然后才能升级mysql。

#10 楼

从5.1升级到5.5时遇到了同样的问题。

对我有用：现在不是时间来验证原因。

评论

我有一段时间移动了DataDir，这就是为什么我需要套接字的路径的原因

– zzapper
17年4月4日在15:03

#11 楼

我的系统从Mint 12升级到Mint 15之后，我也遇到了这个问题。我已将/ var / lib / mysql存档，并在升级后放回原处。我从user16081的注释中运行了第一个mysqlcheck，它抱怨mysql.sock。

我使用/usr/sbin/mysqld &启动了mysqld，而mysql_upgrade运行得很好。

评论

这是升级MySQL的一种非常吓人的方法，但我很高兴它为您服务。

–亚伦·科普利
2013年9月16日19:47
@ aaron-copley：实际上并没有完全起作用。 MySQL 5.5.32部分忽略了我的许多InnoDB表。它们出现在SHOW TABLES中，否则不存在。我目前正在尝试使mysql-utilities正常工作，但这是在抱怨缺少python模块。

–Marty Vance
13年9月18日在21:25

#12 楼

我遇到了同样的问题。
我通过包含-S /path/to/mysql.sock

解决了它。在我的特殊情况下，mysql_upgrade的输出为：
将“ mysql”替换为：mysql
将“ mysqlcheck”替换为：mysqlcheck
致命错误：升级失败

，这毫无用处。 --verbose没什么区别。

随便找我，我遵循以下命令，它像一个魅力一样工作：
mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME- p

希望对您有所帮助。

#13 楼

我遇到了这个问题，结果发现，


它需要MySQL服务才能运行
它需要用户名和密码


#14 楼

我遇到了同样的问题。

我通过在/etc.mysql_install_db --user=mysql文件的注释中通过rc.mysql安装新数据库来解决了这个问题。 mysql守护程序，并使用“ mysql”或您要与mysql软件包连接的任何对象。

我在slackware arm上遇到了这个问题，但假设在这种情况下没关系。

#15 楼

在我的情况下，我在本地运行了几个版本的mysqld，这使mysql_upgrade失败，并显示错误：获取服务器版本时失败！可能是由于未经授权的访问。
ps aux | grep mysql并确保mysqld全部关闭。然后brew卸载所有版本，重新安装正确的版本。之后，mysql_upgrade开始工作。

#16 楼

尝试

mysql_upgrade --verbose


，或者甚至（或两者）

--debug-check --debug-info


评论

尝试过这些，没有真正有用的信息，我认为|;

–吉姆·鲁宾斯坦（Jim Rubenstein）
13年7月30日在20:57
重新启动并粘贴一些错误日志信息\;不知道为什么它会不断循环遍历这些相同的错误。

–吉姆·鲁宾斯坦（Jim Rubenstein）
13年7月30日在21:08
似乎您那里有错误-130730 21:03:34 [ERROR]致命错误：无法打开和锁定特权表：表'mysql.host'不存在，我认为这是导致整个事件失败的原因。

– alexus
13年7月30日在21:09


但在此之前，请尝试mysql_upgrade --version并提供输出。

– alexus
13年7月30日在21:10
mysql_upgrade --version不产生版本输出（仅致命错误）。 mysql --version是mysql Ver 14.14 Distrib 5.5.32，用于使用readline 6.2的debian-linux-gnu（x86_64），并且mysqld版本是5.5

–吉姆·鲁宾斯坦（Jim Rubenstein）
13年7月30日在21:13

#17 楼

MySQL的root用户名为“ admin”，而不是root。正确的命令是

mysql_upgrade -uadmin -p


评论

这是绝对错误的。 MySQL中的root用户是root。

–dr_
16年2月2日在8:28