数据库出了大问题：无法启动、数据丢失、备份失效
--James Qi 2010年5月22日 (六) 12:21 (CST)
本周开始大量导入名录数据到名录集下属的网站中，数据量非常巨大，几十个库，每个都有数十万条数据以上，按照以前的办法估计，全部导入需要数十天甚至更长的时间，而且占用磁盘空间也会非常巨大。于是将原始数据文件批量处理，有几个库同时导入，可没有想到数据库尺寸增长过快，前天凌晨的时候把数据库服务器的磁盘空间占满，导致同一台服务器上面的Squid停止服务，网站都无法访问。
同事删除了部分文件后，磁盘空间依然没有空余，估计是数据库依然在占满，强行reboot服务器后，磁盘空间有了剩余的，squid可以启动，但马上发现mysql无法启动了。我们以为有每日备份，将innodb的log文件删除掉，然后可以重启mysql了，自然原来的innodb库都报错，我们准备导入备份时却发现只有3天前的备份数据，很有可能是最近2天都是因为磁盘空间不够而备份失败了！
没有及时检查备份文件，只有丢失最近3天的数据了，真是太大意了。只好乘着重新导入备份，将以前遗留的共享innodb磁盘文件过大的问题也解决，删除了以前的innodb共享文件，重新生成默认更小的。可能是my.cnf设置上有点问题，innodb备份的dump .sql文件导入后都变成了myisam，不过也好，干脆就换成myisam算了，以前也有人建议我们更换。
在恢复中发现有部分以前从MediaWiki 1.10升级到1.15的网站，导入数据库的时候会在categorylinks, jinglejob 和 page_restrictions这三个表报错而导入失败，这应该也与innodb备份导入变成myisam有关，不过这三个表都有办法来重新创建、生成数据，就是运行maintenance目录下的update.php和refreshLinks.php，数据少的网站很快就可以补充好，而数据量大的网站，refreshLinks.php需要运行很长时间，类似全部用文本导入，上百万条数据的网站可能要运行数十天。不过看上去仅仅是影响category分类和动态页面列表的页面，所以先就让这个持续运行吧，网站主要页面暂时受影响不大，可以对外恢复浏览。
丢失3天备份的问题只好人工来补齐了，从google reader中找到了一些近期更新的数据，再从google快照（需要翻墙工具）找到一些，还用maintenance下的rebuildImages.php --missing来找回图片，算是基本恢复了，肯定有少数网站的少数数据丢失了，但影响不算太大。
最大的问题来了：在3天前备份的导入过程中，绝大部分数据都恢复成功，可查号吧网站的数据却总是中途报错和停止，经过反复检查，发现竟然是.sql的dump文件没有把所有的表都的导出来，只有前面的3、4个表，后面的30多个都丢失了！而这个网站是数据更新最频繁，访问量最大，最重要的一个网站。备份文件只有500M，而innodb file-per-table打包出来的压缩文件就有2G多，解压有近10G，也就是主要数据都没有备份到，这次就麻烦太大了！！
未完待续，正在设法解决中... ...
| 标签：数据库、备份、MySQL、故障。 |
相关内容：
|
