赶集网三年 DBA 总结（转）

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 了。

---

对赶集的记忆已经愈来愈模糊了，惟有...

总结写了一部份后，原同事都说遗漏了一些，那就一齐追加到后面，版权不归我:)

---

20170214 下面内容来自原同事： 李瑞

回忆下赶集的dba生活

总结下就是各类故障多，随时候命，须要处理，这些直到automan出来，强制rd经过平台上线后，稍微好点。

1. 由于raid0的问题，至少遇到4-5次master硬盘的问题，须要紧急处理。
   tg 遇到1次，ms 切过次，貌似也是磁盘的问题。
   其余slave 备份机，硬盘出故障更是多，最多一周须要处理4起磁盘的问题。而赶集的mysqldb 广泛都大至少100G，数据报表库的磁盘有2.3T，无法经过备份的方式重架从库，我用了2-3周才搞定

2. im 的swap 问题
   Im 的swap问题，确定是sql的问题，主要的查询sql 是经过order by，count 来获取数据，这个问题，从我进去赶集到出来一直是没法解决。只能是手动lvs切流量，重启slave，再lvs回切流量 解决swap的问题。1周几乎须要1-2次。告诉过im同事几回im sql问题，但愿对count查询能够本身作个计数器，不过最后也没下文了。关闭swap 又怕服务器会常常oom。 最后仍是赵慎举同窗来了后，开启了预热innodb_buffer_pool的参数后，能够直接重启slave，而不怕由于预热的问题load突增。其余赵慎举同窗改了numa限制内存，不过im的swap是最后也没解决。

3. 备份
   备份的问题，1是磁盘空间的问题，1个仍是raid0的问题。。
   最后大家走后，有1个月我独立支撑，直到毕常奇来了，6台，仍是7台备份机，硬盘坏的是此起彼伏。 Log库，emp，还有王绪峰组,我忘记了业务线的名称了，暴涨到800G的数据，备份机坏了，再加上空间不足。我索性停了备份，最后只保证了ms，hp,tg,tc一些大库的备份，这个58同事接手后估计会被他们鄙视坏了。
   这个其实后来华为32T的备份机来了之后，备份机制应该变通的，怪我
   还有异机备份，每2个月 4个2T盘就会保存满了，更换，挪盘，手动作raid挂盘，手动excle作记录。最后还真有次要用到这些盘查找数据。

4. 磁盘问题
   Hp 俩个大表，须要按期清理数据。Ms 磁盘天天10G的增加速度，并且ms须要用pcie卡，最后终于能够从800 扩到1200。能够消停几个月。Ms 有几个台机器，最后就差10G 左右就要满了。各类删日志，各类挪数据，东墙补西墙，（搞的我知道400G 的ssd 作xfs 要比ext4 能省20G 的空间，刚恰好够给ms用），并且磁盘的增加，伴随着备份机，磁盘空间不足，sim机（提供只读服务给开发的我忘记叫什么了）空间不足。还有report库，想申请磁盘，服务器，机柜没有位置了，就那样挺着单库跑了好久。

5. 还有就是王绪峰组 和tc 的 经过框架生成的sql
   生成多余的子表，varchar 类型的字段条件不加单引，再加上上线建表不加索引，按期须要检查sql，进行优化。

6. 痛苦的hp，主库拆分。
   历时1年多，没有分拆完整 。最后听毕常奇说，瓜子二手车从这些库里拆分。自上而下，强行拆分。1-2天拆分了。

7. php的短链接，链接数满
   这个最后的最后，大家走了后，偶尔在分析hp全日志，发现hp每1-2次链接，伴随着一次空链接。Connect 什么都不作 quit。这个问题不知道什么有的，改了后，hp的链接数问题好了。

---

总结，在赶集，由于数据的暴涨，只是一味的应对，没有快刀斩乱麻，进行分拆。还有就是有个dba的平台真是很必要，管理监控，提交审核sql，这个直到后来在完美一天的时候我才可以模仿着automan勉强写了个。

做者：董泽润 连接：https://www.jianshu.com/p/58962c334a35 来源：简书 简书著做权归做者全部，任何形式的转载都请联系做者得到受权并注明出处。