• 我的3年赶集DBA生涯
  • 小静 发表于 2017/2/17 21:56:00 | 分类标签: 程序员 码农 赶集网
  • 2012年初入职赶集,当时处在流量讯猛增长的阶段,3年DBA生涯收获坡多,其实坑更多(泪… 后来在做开发时,慢慢体会到 ”运维“ 和 “开发” 确实存在沟通问题:知识不对称。如何解决呢?先总结下这三年吧

    DBA职责

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

    • 数据库系统的规划、设计、管理、迁移
    • 数据库的日常维护、备份、优化及恢复
    • Master-Slave架构搭建、维护
    • 业务系统上线支持,数据库设计评审,提供架构方案

    数据库不局限于 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。

    反思:这个事故得站在高处去看,免费端口开放太突然,项目技术负责人考滤不全。报表系统没有经过设计,完全由一个新人RD去搞,也就大学毕设水平,回头再看,hadoop spark 完全搞定。最后 DBA 没有及时对大表进行跟踪,没有提前发现。

    5. 50G的Redis

    房产业务 Redis 眼看从 20G 爆涨到 50G,我离开后也一直没优化掉。后来某次故障,数据清空了?


    我的工作

    大部份时间和开发沟通感情聊人生,后来 automan 上线很少有人找我了~ 每个阶段都有成长,都有感谢的人和事,赶集让我有平台去做感兴趣的事,很开心。

    刚到赶集时,SQL 上线还走的 jira,半自动化由运维开发同学做的,经常在技术大群里被艾特,很简单的建表或是DML 都要由 DBA 人工介入,很烦索。另外很多建表语句不规范,打回让 RD 修改,他们对此很有意见,认为无所谓的修改,这就在 RD和 DBA之间产生了沟通成本,诗展在的时候还会定期做数据库开发培训,然后就没有然后了。

    14年中着手 automan 平台开发,从前台页面到后端消息队列,到 sql parser 解析,从无到有,在刘军先河同学的帮助下最终上线完成。由平台去审核开发的 SQL,经过 sim 模拟环境,再到线上自动执行备份,比人工高效的多。

    这个系统原理和市面上其它工具差不多,扔有很大改进的地方。后来在数据库大会分享了一次,诚惶诚恐没有被喷。

    DBA 心得

    • 夯实基础:DB 的基础自然是稳定,稳定,再稳定。实例数一多,基本每天都会遇到各种故障。主挂了就用 MHA 切换(最新的有gtid),slave 挂掉就由 lvs 自动摘掉读流量。还有一个就是备份,全量增量,定期备份有效性检测,每一块都需要人力的投入。
    • 硬件优先:DB扩容有 scale up 和 scale out 两种,一般优先堆硬件。buffer 不够加内存,128G 不够就 192G,磁盘阵列卡性能不行就上 SSD,再不行就上 flash 板卡。总之优先考滤硬件,争取架构优化的时间。
    • 未雨绸缪:慢 SQL 优化,定期出报表让 RD 调优,一般出问题都是索引没加,99%的大SQL都是这样,少部份因为表设计不合理(没有自增主键,或是频烦修改)。大表监控,该瘦身的瘦身,字段该拆的拆,横竖两刀,过期数据定期归档,基本上就这些事。
    • 结合业务:有些优化 DBA 累的半死,不如 RD 修改一行代码。DBA 也要多和业务接触,了解业务实现,不求给业务贡献多少,不背锅就好… 开玩笑。了解业务,就能站在更高的角度去思考,很有意义。
    • 学会拒绝:这个拒绝不是罢工不干活,而是要分清哪些需求的合理性与紧急性,不合理也不紧急的直接干掉,紧急但不合理的可以临时通过,快速解决问题,事后再确掉也可以。比如 olap 跑在了线上库,count(*) 计数 SQL 完全可以异步走计数器,Redis 是好东西。
    • 学会沟通:工作也有些年头了,这一点仍然在学习,也犯过不少错。沟通好权责,定下时间表。
    • 踏实学习:回头看当年DBA做的不够好,有些原因在于没有开发能力,很多想法止步于此。运维人员一定要有开发功力,并且要比业务 RD 更精,才能做好运维。

    运维RD的矛与盾

    KPI 不同,关注点自然也不同,一线的同学经验也都有欠缺,特别是刚工作1~2年的,造成了信息与知识的不对称。解决这个问题也不难:

    • 新人要有导师带,对新人放手不管最不负责。这方面感觉 nice 做的不错。该夸还是要夸的。
    • 支撑团队要有足够的 wiki 业务文档说明。
    • 自动化用技术来约束,而不是人工。同比业务接口强约束,现在服务化都用 thrift 了。

    对赶集的记忆已经越来越模糊了,唯有…

  • 请您注意

    ·自觉遵守:爱国、守法、自律、真实、文明的原则

    ·尊重网上道德,遵守《全国人大常委会关于维护互联网安全的决定》及中华人民共和国其他各项有关法律法规

    ·严禁发表危害国家安全,破坏民族团结、国家宗教政策和社会稳定,含侮辱、诽谤、教唆、淫秽等内容的作品

    ·承担一切因您的行为而直接或间接导致的民事或刑事法律责任

    ·您在编程中国社区新闻评论发表的作品,本网站有权在网站内保留、转载、引用或者删除

    ·参与本评论即表明您已经阅读并接受上述条款

  • 感谢本文作者
  • 作者头像
  • 昵称:小静
  • 加入时间:2013/7/17 0:00:00
  • TA的签名
  • 这家伙很懒,虾米都没写
  • +进入TA的空间
  • 感谢以下赞助商
分享按钮