无厘头的mysql故障排除

dengwen3

　　公司网站已经趋于正常,作为系统管理员终于可以暂时的舒一口气.在继续持续关注服务器管理与优化的同时,可以有时间停下来回顾,总结,为不断的提高积蓄能量.
　　先说一个让我哭笑不得的mysql故障吧.
　　新版网站准备上线,由于一些架构上的调整,一向喜欢条理清晰的我,决定把旧网站的数据库清理一下,删除一些无用的库和帐号.因为旧版网站还没有下线,所以在操作数据库的时候,我也是格外小心,尤其是进行这种删除操作.很快清理完毕,访问旧版网站一些正常,ok,估计是没啥问题了.于是开始着手新的网站搭建,新建立正式库,建立帐号严格考虑帐户名和密码强度以及数据库的权限.导入新的库,一切进行的有条不紊.通过新版的测试域名访问网站,一切正常.看来要很顺利的完成新版环境的搭建了.等吉时一到,域名一切就ok了.
　　然尔,然尔,玩笑总会在不经意间等待着你.午饭归来,有同事反应访问一个页面的时候mysql报了一个错误:
　　ERROR 1449 (HY000) at line 2884: There is no 'xxx'@'%' registered
　　xxx?@%? no registered?首先访问网站的时候数据库帐号不是xxx@%!我迅速确认了一下网站的数据库配置文件,写的没错啊?而且也不是xxx@%.难道是建立完帐号,没刷新权限?用root连上mysql执行一下'flush privileges',再访问那个页面还是同样的错误;为确保不是权限的问题,迅速重启一下数据库.成功重启,再次访问那个页面还是同样的错误!怪了,这时候思绪还是在权限上打转.用新建立的帐号和密码,访问数据库,没问题啊?可以正常连接.desc那个页面查询的表,于是出现了上面的提示!邪门了,用这个帐号登陆查询的,怎么会提示一个完全不相干的帐号 no registered呢?期间做开发的同事告诉我说,中午修改了这个表的表结构.可是想来想去,和这应该也没关系啊?反正是网站还处于测试状态,将库导出来,删除帐号,删除库,重启数据库,再新建帐号,刷新权限.再用那个帐号连接,desc表结构,还是报同样的错!
　　有点抓狂了.虽然是测试网站,但是已经是公司范围内测试了,大家陆续发现了这个问题.我的脑子以7200转/秒的速度疯狂运转.不是数据库用户权限难道是物理权限问题?两年前的时候遇到过一次有人误操作修改了数据库所在目录的根目录的权限,导致数据库无法启动的情况.mysql数据库,对物理权限检查非常严格,从根目录到数据库所在的目录,必需是root用户和组所有,数据库目录归运行mysql的帐号完全所有.于是迅速检查一下物理权限,一层一层的看过来了,没问题啊?还是不放心'chown root.root '强制重设目录权限,再试,还是报同样的错.真是邪门!整个公司的人都在等数据库了,怎么办,怎么办,怎么办?在那一刻,真得,觉得工作好难熬(半年的时间里,出现了好多无法解释,而又无缘无故的恢复了的问题.最近又崩紧了一根筋,准备网站的上线).好想说一句放弃,然后撒手不管.但是我已不是三两岁的小孩子了,可以把自己解决不了,或者不愿面对的问题丢给父母.一咬牙,我对自己说:不能放弃!心里苦笑,安慰自己:男人在很多时候的意思就是'难人',低下头,静下心来,继续解决问题.几秒钟以后,我已经缠着google大叔问个不停了.
　　出现这样问题的,大多是mysql,5.0以后的版本,而翻来翻去,连mysql官网上也有这样的问题求助,竟没有一个解决了先例!我就郁闷,有那么巧,这么难搞的问题让我遇到了?几分钟以后找不到任何有用的信息,我决定还是独立思考这个问题.经过先前的尝试和后来的网络搜索,我算是迅速学习和理解了我遇到的问题.我决定不再看表象,而是从根处找原因.为什么会出现这样的提示呢?想来想去,记得很久以前的一个测试库里,有建过一个帐号叫xxx@'%'.不能吧,完全不相干的库和完全不想干的帐号.因为正好自己手工清除了这个帐号,决定先恢复这个帐号试试.恢复完了,再通过desc可以正常列出原来无法查询的表的结构了.页面访问也没问题了!
　　问题解决了,但是我不甘心,因为这个无厘头的故障导致我十几分钟的心里煎熬!翻翻以前的管理记录,发现原来这个帐号给的是全局权限,是当时给的权限太大了?还是因为在删除帐号的时候,删除的太快,没有一个删除跟着一个'flush privileges'?不管了,这个帐号我是铁了心要删除了,既然一下删除报错,那咱来温柔点的,先把这个帐号的权限revoke了.刷新权限,desc表结构,没问题.ok,是时候和你说byebye了.直接delete再刷新权限,再desc表结构,还是ok,呵呵,事实上,半个多月过去了,都没再出现过类似问题:)