分类： 数据库开发技术
2013-04-29 22:11:28
我去年遇到过三次数据事故
1. 去年客户让我们做了一个写评论的活动，但是最后已经评完奖公布了，但是某个获得评论最多的人说发邮件给客户说我没有写那么多个评论，只发了一个。
接下来可想而知，我们被客户骂了，但是我们得确定这个人是否写了那么多评论，代码里是没有删除数据的功能的，但是开发人员在上线前需要导入SQL语句，而且需要把多个用户表进行合并（这个是因为客户要求多个系统的用户都可以登录，而多个系统中的有些用户是重复的），估计合并数据表时出现问题了。在合并时有可能会把某些人的评论加到这个人上，但是程序没有对每个人提交的数据写日志。在数据表里找不到任何有用的东西，都表示结果是正确的。
我冥思苦想后忽然想到可以在mysql日志里找到这个人的提交产生的的SQL语句。
我把mysql-bin的二进制文件转换为文本后，果然在文本里找到了这个人的SQL语句，只有一条。也就是说在用sql语句合并数据表时产生了覆盖的问题。最后查出合并表时SQL语句缺少了一个条件。
教训：执行任何SQL语句之前必须先备份数据表，误操作时可以恢复回来。
2.数据库覆盖问题
有一次我的一个下属在做数据库恢复时出现了问题。
我们的数据库里有好多个网站的数据库，有一次他为了做一次修改，先把A数据库备份下来，修改A的数据，发现不对，由于B和A的名字就差两个字母 于是想恢复回来，于是就执行了mysql B < A.sql，就把B给覆盖了，结果就导致B网站的内容变为A网站。
当然可以从日志里恢复，但是日志太大了，恢复时间非常长
还好还有一个是一个月前备份的B的数据库SQL文件，很快把B恢复回来了,但是这个月的修改都得重新来啊。
教训：恢复时不要轻心大意，执行覆盖前确保数据库或者表名正确
3. 由于监测发生的数据泄漏事情
有一天发现在google上能够搜索到我们网站的用户信息页，查了很久发现 这个问题是由于加了google analytics导致，在我们网站的后台中包含了一段GA的代码，用于监测用户使用某个功能的情况，结果google analytics的数据被用作爬虫的源，可想而知，我们后台的页面就出现在搜索引擎上。这个也是我们的某些页面的代码不规范缺少验证导致。
4.其余经验:
对于nosql数据库，最好使用防火墙控制访问，限制外网访问nosql数据库，否则很容易泄漏数据，例如redis数据的6379端口，即使是设置了访问密码也很容易暴力破解，因为redis每秒钟可以尝试登录15k次
