2013年08月22日,一个关于用户数据的血案导致两位开发人员,一位DBA,一位业务运维通宵加班恢复用户数据,史称822血案;
此血案由一个名叫mysql_escape_string的函数导致;
下面将此血案的发现、初步解决、定位以及最终解决的过程记录如下,涉及到相关的知识点也顺便记录。
【血案出现】
8.22上午9点,开发接到数单用户投诉,用户投诉的具体内容为:半小时前登录XX游戏,自己的荣誉、成就、任务全部被清空;
由于是同一时间段接到数单投诉,引起开发重视,于是立即登录Server查看原因。
涉及到此业务的Server架构如下(为了简化说明问题,只把涉及此业务的架构剥离出来):
1、迅速ssh到业务AServer,发现AServer正在狂刷某类型Log;(有同事会疑惑Svr没部署监控告警吗?实际是此类型Log在某些情况下是正常的Log,所以没有监控此类型Log);
2、ssh
mysql_escape_string导致的数据回滚
最新推荐文章于 2021-07-02 14:06:01 发布
2013年8月22日,由于使用mysql_escape_string函数导致的数据库错误,使大量用户数据丢失。在回滚数据库并定位到问题源头——升级过程中blob字段长度配置不当后,通过恢复备份和修复bug解决了问题。事故提醒我们,版本发布应遵循灰度原则,并进行外网验证。
摘要由CSDN通过智能技术生成