Ubuntu 升级后 MySQL 无法启动

上一篇文章中我说道，我遇到了 MySQL 的严重问题。在这里专门说一说。

当时我写好了程序，已经通过 FTP 上传到服务器上了，然后就上服务器上调试。由于近期 Ubuntu 12.04 LTS 出来了，因此每次我登陆的时候，都会有升级的提示，让我运行 do-release-update 来升级。因为我用的是 VPS，我不确定 Linode 是怎么说这个事的，是不是有问题，因此我在这半个月中一直忽视它。今天又看到了这个提示，觉得大概是时候把它处理一下了。

于是我搜索了 Linode 的页面，看到它的 blog 上写的可以升级。我过去在用 Ramhost 和 YardVPS 的时候都做过这个，因此虽然脑子里想的是不是要备份一下数据库，但考虑到过去都很顺利的通过了，于是就没有再管，直接升级了。

升级中间出来一个窗口，让我设置 MySQL 的 root 密码。虽然我过去设置过，但我这次还是重新输入了两次，接着提示我说设置 root 密码失败，原因可能是我过去设置过 root 密码，或者是配置出了问题。我一看，我过去设置过 root 密码啊，于是就没有考虑这个，直接选择继续了。

升级结束后我开始测试我的程序。我选择了手动创建数据库，但在运行 MySQL 客户端的时候，却出现了错误信息：

ERROR 2002 (HY000): Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (2)

无论我用普通帐号还是 root 帐号都出现了这种问题。开始时我以为是个小问题，于是重启 MySQL，结果发现启动不起来了，运行 service mysql restart 的结果是：

start: Job failed to start

这时，我意识到可能是 MySQL 系统出问题了，去浏览器访问我的 blog，果然提示数据库连接不正常。

我上网搜索，确实有人有过这种经历，但原因是因为硬盘空间满了，清除出一些空间来就解决了。还有人说跟 /var/run/mysqld 的权限有关，我试过修改权限，但仍然不管用。

这时我有点着急，因为我的数据并没有备份。系统升级这种事我做过几次，都很正常，从来没有出现过这种情况。如果我又数据库的备份，我大不了重新做一次系统，然后把数据导入回去就行了。现在却没办法了。我尝试着备份了 /var/lib/mysql 目录后删除 MySQL，再重新安装 MySQL，结果还是不行。

我查看了 /var/log/mysql/error.log，结果里面相关的内容是：

120514 11:16:44 [Note] Plugin ‘FEDERATED’ is disabled. 120514 11:16:44 [Note] Plugin ‘InnoDB’ is disabled. 120514 11:16:44 [ERROR] Unknown/unsupported storage engine: InnoDB 120514 11:16:44 [ERROR] Aborting

120514 11:16:44 [Note] /usr/sbin/mysqld: Shutdown complete

我看了半天也没怎么看出门道来，InnoDB 我在刚开始安装 MySQL 之后马上就关上了啊，普通的网站根本用不到 InnoDB，而且它又十分的耗内存，因此这是 VPS 的内存优化必做步骤之一。

我只好又查其它的文档，也做了不少尝试。比如说，配置文件中的 default-character-set 选项过期了，新的选项是 character-set-server，等等。我改了一些这种选项，但总是没有效果。

最后，我因为错误记录中提到了 InnoDB，就抱着试一试的心情，把配置文件中的 skip-innodb 这一行给注释掉了，结果启动 MySQL，竟然成功了。我无论如何也想不到竟然会在这个地方出问题。

解决了问题后我成功的让我的程序可以访问 MySQL 数据库了。然后我想找找为什么关掉 InnoDB 会让 MySQL 无法启动。当我检查我为了这个程序所创建的数据库时，惊讶的发现了这个数据表竟然使用了 InnoDB 引擎，而不是我以为的 MyISAM。抱着这种猜想，我搜索了 Google，果然发现了，从版本 5.5 之后，MySQL 默认的引擎成了 InnoDB。

这让我非常惊讶。因为在我的印象里，除非像 Wikipedia 这种类型的网站，会有在统一时间更新数次数据的情况，一般的网站都不需要用 InnoDB 的。而关闭 InnoDB 会节省至少 80MB 的内存，这对于 VPS 来说时比较重要的。因此，应该会有更多的人需要 MyISAM 而不是 InnoDB 才对。结果 MySQL 不声不响的把默认的存储引擎就这么给换掉了。

更重要的是，MySQL 对于这种情况处理的太粗暴了。默认的存储引擎是 InnoDB，配置中却关闭了它，那么就用第二顺位的引擎不就行了么？当然，或许设计者有其它方面的考量，但我觉得这已经属于向下不兼容的升级了，错误信息中至少放一些提示吧。

找到了问题的原因之后，我检查了一下内存使用情况，发现 512MB 的 VPS 目前虽然启动了 InnoDB，但内存方面还是比较有余的，因此我也没有调整存储引擎这方面，打算渐渐的体验一下 InnoDB 试试。