搜狐首页 科技 栀子花开

手机搜狐

SOHU.COM

经验分享|赶集网三年DBA的总结

2012年初入职赶集,当时处在流量讯猛增长的阶段,3年DBA生涯收获颇多,其实坑更多(泪...后来在做开发时,慢慢体会到”运维“和“开发”确实存在沟通问题:知识不对称。如何解决呢?先总结下这三年吧

DBA职责:

市面上招聘 JD 一大堆,随变找几个,马上能找出共性

数据库不局限于 MySQL, Oracle, 如果分的不细,还会有 Redis, MongoDB 等一系列 NoSQL。工作内容都一样,首先是高可用稳定性,不能今天抖动明天宕机,涉及工作很多。第二个是数据安全,比如备份及恢复,14年赶集审计,移动端的活跃用户数就是从备份中恢复来的,可见备份的有效性是重中之重。最后一个当然是为业务服务,对接业务需求,不能因个人生活被打断就罢工,有一次刚看电影就被叫回去处理DB报警,骂娘的心都有了。

悲惨案例:

先举一些悲惨案例,让看官们高兴一下~ 由于公司早就不在了,这里没有顾忌。

1. delete 删全表

二手车同学的锅,SQL 拼错不带 where 条件,编写线下脚本时出错... 最后DBA根据 row binlog 恢复。至少2次:(

反思:rd 新手一茬又一茬,规范讲再多也没用。最彻底的解决方式只有一个,接入 proxy, 限制一切非法 sql。另外 rd 上线验证也不到位,代码 review 肯定有缺失

2. 大卖家问题

房产在14年开通免费端口,短短几个月时间房产商业表爆涨到 100G,个别中介帐号发贴超过10W,导致数据库异常抖动,威哥临时清理过多发贴记录解决。最后耗时三个月对这张表进行瘦身,拆分 text 字段。

反思:DBA 对大表监控不足

3. 大量子查询打跨主库

主站主库有一次被子查询打跨,事后排查,由于 RD 大量子查询导致。此类问题不是个案,有很多 RD 把本本该读 slave 的请求写到 master 上,只不过没有引起事故而已

反思:赶集 DB 典型 1 主 N 从,没有 proxy 保护的怀况下,经常出现此类问题,只靠规范制度基本解决不了

4. 报表 olap 库问题

RP 库我和文武背锅,年底的绩效垫底。文武接手前的 RD 一个人开发中介商家报表系统,所有计算都是基于 DB,当免费端口开放后数据量爆涨,MyISAM 读写锁导致大量请求阻塞,听说公司因为报表连续问题赔商家300W。

精选