mysql_upgrade失败，没有给出真正的原因

70

我正在从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  mysql5.5 
— 吉姆·鲁宾斯坦
source
也可能没有价值，mysqld正在运行，带有--skip-grant-tables选项。我可以mysql在没有凭据的情况下通过终端进行连接，并且通过syslog或运行时可以想到的其他任何地方都没有错误mysql_upgrade
— Jim Rubenstein 2013年
在MySQL参考手册涵盖了从5.1升级到5.5很好。如果您按照此处的所有说明进行操作，那么值得一提。如果您还没有，那么...
— Aaron Copley 2013年
如果您的mysql超级用户没有密码，则不要在mysql_upgrade -u root -p中包含-p
— Jeferex

Answers:

95

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

mysql_upgrade -u root -p

如果我不通过他们，我会得到你的错误

编辑：感谢现在的评论，我知道还有其他原因，也许不那么频繁，但是最好也要注意它们

所以当你遇到错误

  • 您没有通过用户名和密码
  • 您通过了凭据，但是他们错了
  • MySQL服务器未运行
  • 权限表被破坏（然后您必须使用重新启动MySQL mysqld --skip-grant-table）
  • 表mysql.plugin丢失（启动MySQL时会提示运行mysql_upgrade并显示错误，并且失败。您可能在my.cnf中有一些过时的配置）
— 里卡多·加利（Riccardo Galli）
source
23
这正是我遇到的问题-为什么不能说“无法验证”或“连接错误”之类的内容？太生气了……
— les2
3
伙计们，如果您的密码也是错误的，也会收到相同的错误。所以被告知。
— Yoosaf Abdulla 2013年
3
如果服务器没有运行，即使它似乎接受密码，您也会收到相同的错误。
— 拉曼
1
只是当数据库表或数据库格式也损坏时，它也不起作用，那么您需要使用“ mysqld --skip-grant-tables”启动守护程序，并在另一个终端上运行mysql_upgrade！
— 亨宁2014年
为此+1。然而，我恨MySQL的另一个原因
— 神剑
9

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

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

— 奥布里·法尔康纳（Aubrey Falconer）
source
那正是我的问题，因为我这样运行mysqd：mysqld --skip-grant-tables --user = mysql
— Rodo 2014年
9

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

mysql_upgrade -uadmin -p`cat /etc/psa/.psa.shadow`
— linuxman1
source
这对我来说非常有效
— xarlymg89'6
5

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

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/en/mysql-upgrade.html

— user16081-JoeT
source
1
对此进行了考虑，但是fix_priv_tables它是mysql_upgrade为了修复特权表而生成的脚本
— Jim Rubenstein 2013年
好点，也许只是尝试第一个mysqlcheck行？并尝试直接从bin文件夹，运行FWIW，/usr/bin/mysql_upgrade
— user16081-JoeT
3

这个问题简直太笼统了，对此我深表歉意。

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

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

— 吉姆·鲁宾斯坦
source
是啊曾经的MySQL数据目录已损坏，有你可以做几乎没有什么
— Krauser
2

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

chown -R mysql /var/lib/mysql
— 阿索菲扬
source
2

我们的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背面恢复为原始状态（首先检查您应添加的任何新默认设置！）

  • 使用diff工具，例如vimdiff，将diff工具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。
  • 利润。
— 罗尼
source
1

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

— 莱安德罗·达迪尼（Leandro Dardini）
source
1

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

这为我工作： sudo mysql_upgrade -S <path-to-socket> -u <myuser> -p<mypass>

我的错误可能是由套接字路径的权限引起的，但没有时间验证它是原因。

— 上尉
source
我会提出我的DATADIR在某些时候，我想这就是为什么我需要的路径插座
— zzapper
0

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

我开始使用mysqld /usr/sbin/mysqld &并mysql_upgrade运行良好。

— 马蒂·万斯
source
这是升级MySQL的一种非常可怕的方法，但我很高兴它为您服务。
— 亚伦·科普利2013年
@ aaron-copley：实际上它并没有完全起作用。MySQL 5.5.32部分忽略了我的许多InnoDB表。它们出现在中SHOW TABLES，但不存在。我目前正在尝试使mysql实用程序正常工作，但这是在抱怨缺少python模块。
— 马蒂·万斯
0

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

在我的特殊情况下，mysql_upgrade的输出为：
查找“ mysql”为：mysql
查找“ mysqlcheck”为：mysqlcheck
致命错误：升级失败

那真没用。--verbose没有影响。

随便插入，我决定使用以下命令，它像一个魅力一样
起作用：mysql_upgrade -S /var/lib/mysql/mysql.sock -uUSERNAME -p

希望能帮助到你。

— 菲伯
source
0

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

  1. 它需要MySQL服务才能运行

  2. 需要用户名和密码

— 苏瑞特·苏克
source
0

我遇到了同样的问题。

我通过mysql_install_db --user=mysql按照rc.mysql/ etc中文件注释中的说明安装新数据库来解决此问题。

然后，我能够启动mysql守护程序并使用'mysql'或任何您想与mysql程序包连接的东西。

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

— 用户名
source
0

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

— 劳伦斯·布朗瓦瑟（Laurens Bronwasser）
source
-1

尝试 

mysql_upgrade --verbose

或什至（或两者皆有）

--debug-check --debug-info
— 亚历克斯
source
尝试过这些，没有真正有用的信息，我认为|;
— Jim Rubenstein
重新启动并粘贴一些错误日志信息\; 不知道为什么它会不断循环遍历这些相同的错误。
— Jim Rubenstein
似乎您在这里有错误- 130730 21:03:34 [ERROR] Fatal error: Can't open and lock privilege tables: Table 'mysql.host' doesn't exist我认为这是导致整个事件失败的原因。
— alexus
但在此之前，请尝试mysql_upgrade --version并提供输出。
— alexus
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
-3

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

mysql_upgrade -uadmin -p
— 马可·马尔萨拉
source
这是绝对错误的。MySQL的root用户是root。
— dr01
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.