关注的朋友们应该会能发现俺的博客这两天抽风了，从5号晚上开始先是数据库链接失败，而后是网站一片空白，像是刚建的一样！SAE没有报故障，这一切是我自己手贱造成的。
起因是我忽然想起自己很久没有清理数据库了，自算数验证码去掉之后，我有很长一段时间都没关注那些疯狂的垃圾留言，事实上那些东西也不值得我去关注，顶多就是把一些看着不顺眼的留言丢入垃圾，以往的经验告诉我这些垃圾留言即便你删掉，它后台数据库里也还是有记录的，名为“wp_commentmeta”（表的前缀具体因人而异，不一定是wp）的表里保存着Akismet插件对留言处理的记录，日积月累下来它会慢慢变得比文章数据本身更加庞大。网上推荐博主不定期对其手工清理一下。名曰瘦身减压。
5号晚吃饱饭撑着之后想起这件事，便打开了SAE的管理后台准备手动清空那张表，照着前辈嘱咐操作前备份了一下，如今回想，如果SAE提供的Deferred Job（递延队列任务）导出数据库的效率，能像导入一样慢就好了。说不定我等着等着就可能将这事给忘掉，而后便没这场风波。偏偏对多数系统而言数据读取效率都是比写入效率高的，博客的数据库很快就备份出来了。有了备份我就大胆，紧接着对那张表点了删除，系统跳了个提醒，对，就是删除！等看到数据库里少了一张表之后，我才想起哪里貌似点错了！
对大神而言，重建一张表不是啥困难的事，可我不是大神，玩独博至今我连那张表的结构是啥样都不清楚，想着重建麻烦也就算了，不如用备份还原来得方便，为了防止数据冲突，我又毫不犹豫删掉了整个库里所有的表，在Deferred Job那提交了个数据导入任务后就一直等着。
基于系统的限制，SAE不能直接导出大批量数据，对MYSQL的操作一般都得通过“递延任务”，由系统安排合适的空闲时间执行，而我本人基于对SAE的信任，以往都很少接触这所谓的Deferred Job服务。过往极为有限的几次经验告诉我顶多等个五六分钟罢了，没想到我5号晚上八点半提交的请求，一直到6号凌晨一点多才得到执行，那时候我早已进入梦乡了。
昨天早上醒来后我用手机打开了博客瞧瞧，页面空白一片连个报错提示都没有，好吧，不报错也算好的开始，以为是后台设置需要调整一下，我也就不着急了，等洗漱完毕弄完早餐再坐到电脑前进入博客后台，输入了账号密码进不去，提示我没有权限……我确信是新的问题冒出来了。
网上说这类问题在恢复数据库的时候会有碰到，大约是修改数据表前缀后，对应数据库内关键内容没有跟随修改导致报错，解决方法是五花八门，我没那个耐心学习便打算用更简单的方式解决问题，即重装博客，构建个完全一样的数据库后再执行数据导入！想必不会再出问题了吧。
法子想好了便立刻实施，基于安装文件都在的，博客重装也就极为简单，直接删掉数据库再初始化即可。清晨的时候执行数据导入是很快的，文章评论什么都回来了，可不知道是系统哪里出了问题，我发现自己后台的设置全无……比如邮件账号设置、邮件订阅地址、文章更新ping通知的地址、以及固定链接地址、主题菜单设置等等，要全部重设也很麻烦，我觉得不对劲，照理说配置也都在数据库里，可自己折腾那么久也只恢复了文章跟评论数据，设置没跟着恢复，这很奇怪！
我正想着，算了，干脆手工重设吧，奇怪的事情又来了，我输入的很多配置，比如固定链接地址格式，还有那个缩略图参数什么的，连着好几次都无法保存，最后一次再试又莫名其妙成功了，而后我回到访客界面，发现刚才还是空白的菜单居然复原了，旁边的小工具我还没来得及重设，也跟着复原了……
而后我开始明白了，这都是缓存的问题，SAE的数据库很庞大，导入的配置还没来得及写入我就输入新的数据，缓存写入跟我手工输入产生了冲突以至于我无法保存。我若不着急的话，配置最终都会回来的，可我急着操作，新旧覆盖之后，却真的丢失部分配置了！
真可谓吃一蜇长一智，明白了这点之后我变得懂得后面怎么操作了，推倒重来吧，再次提交数据导入任务，那时候已经是白天SAE系统繁忙时了，这次导入请求又得一直等着……等着……！
联想5号阿福的方室网志正好也遇到了故障，机房掉线之后被迫做IP调整，而我则是不折腾就完全没事，想来那真是咱俩博客的不幸之日呐！自嘲手贱的同时我想了想，这博客如人，安逸太久了，总要来一场大病才好！
(暂无人赞)
Loading...
(1个赞)