"Table 'mysql.plugin' doesn't exist"引发de血案

素颜马尾好姑娘i 2022-07-13 10:45 128阅读 0赞

> 只是将自己在开源中国上的博客搬过来。  
> **软件**：阿里云服务器上的MySQL  
> **人物**：我和师弟两个菜鸟，我在广州，师弟在西安  
> **时间**：2016年4月  
> **起因**：某天一大早发现服务器上的mysqld没运行  
> mysql log-err: mysqld\_safe Starting mysqld daemon with databases from /usr/local/mysql/data  
> /usr/local/mysql/bin/mysqld: Table ‘mysql.plugin’ doesn’t exist  
> \[ERROR\] Can’t open the mysql.plugin table. Please run mysql\_upgrade to cr…

回过头想想，一开始查下`mysql_install_db`这个命令，也不至于承受着巨大的压力折腾两天，不得不说，折腾下来的收获真的不小，好记性不如烂笔头，记录下来共勉。  
  故事的开头是用`./mysqld_safe`命令起不来MySQL，`错误提示：ERROR 2002: Can't connect to local MySQL server through socket '/tmp/mysql.sock'，`查看/tmp目录中确实没有mysql.sock，又看了log-err:`[ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.` “Please run mysql\_upgrade to create it”，如果一开始注意到这句话用mysql\_upgrade 命令会不会就没有后头的事了。  
  当时使用了`./mysql_install_db`命令，我不知道师弟用的什么参数，指定的配置文件肯定还是/etc/my.cnf，(没想到mysql\_install\_db命令的结果是新建了个数据库实例，并且一般会新建一个xxx.cnf文件)，然后也新指定了datadir,basedir为data目录（以前的在var目录），生成了新的授权表，以及my.cnf文件。`mysqld_safe`可以起来了，感觉自己棒棒的，但是当我们登陆phpmyadmin后彻底傻了，以前的数据库都没有了，没有第一时间去查`mysql_install_db`命令的应用场景，满脑子是闯大祸了，数据被删了，要怎么去恢复数据库，要不要请示项目leader，自己先补救再说。。。  
  恢复数据库之旅开始，我们竟然找到了以前/var目录下的所有数据，但是没有想到直接更改my.cnf配置到这个目录就可以，而是坚定的认为mysql的数据库都是默认在data目录的，不能更改，var下的只是副本或者啥的，还是太年轻了T T。我们的做法是用var下的数据去data目录下恢复，使用.frm文件恢复了表结构，按internet上说用ibdata1去恢复数据，但是就是不成功，都没想到用mysql-bin.00000x文件去恢复，还是因为太年轻T T。中间还有一个重大的插曲，ssh不能连接到阿里云服务器了，没办法，只好将这件事告诉了项目leader，好的是他让我别着急，我能不着急吗，这数据要是真没了责任都是我的T T。之后leader给阿里云打电话，工作人员说云上有近三天的快照，leader说他晚上去恢复到某一天快照，让我们不要担心。确实是松了口气，刚好也到下班时间，晚上吃了顿好的，以缓解我白天的压力。  
  然而第二天一大早leader打电话说，快照里头没有还是怎么的，总之就是通过快照不行，还是得自己搞。ssh链接不了是因为linux的var目录被谁删了，扶额，哪个缺心眼干的，没事喜欢乱删。又开始折腾着恢复数据，internet上的方法看的多了，大都是复制之类的，我就想能不能直接指定配置文件中的路径到./mysql/var呢，反正所有文件都是从var目录cp的。说干就干，mysql起来了，但是登陆进去后每个数据库是空的，然而磁盘上每个数据库中是有.frm文件的，查看日志，”Cannot find or open table xxx from the internal data dictionary of InnoDB through the .frm file for the table exists. Maybe you have deleted and recreated InnoDB data files but hava forgotton to delete the corresponding .frm……, the table contains indexes that this version of the engine doesn’t support.”这段英语说个啥信息，先不管，先给mysql用户赋予权限试试，重启，又看到了熟悉的数据熟悉的表！！！结束~  
  后记：  
  今天（2016/4/25）大早上，甲方工作人员告诉我录入数据提交不成功，我看到控制台报：`#1030-Get error -1 from storage engine`，原来是前几天捯饬MySQL的时候在my.cnf加了一个参数`innodb_force_recovery=4`，插入操作被忽略。注释掉或者设置为0就可以执行正常操作了。

>   回过头来看自己之前写的博客，解决问题的方式太嫩了，上述所出现的问题已经不能复原，不管怎么说，人都是一步步在成长，短短半年自己的变化还是看的见得，2017自己一定会更好！