2013年初入职赶集，当时处在流量讯猛增长的阶段，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通过平台上线后，稍微好点。
因为raid0的问题，至少遇到4-5次master硬盘的问题，需要紧急处理。
tg 遇到1次，ms 切过次，貌似也是磁盘的问题。
其他slave 备份机，硬盘出故障更是多，最多一周需要处理4起磁盘的问题。而赶集的mysqldb 普遍都大至少100G，数据报表库的磁盘有2.3T，没法通过备份的方式重架从库，我用了2-3周才搞定
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是最后也没解决。
备份
备份的问题，1是磁盘空间的问题，1个还是raid0的问题。。
最后你们走后，有1个月我独立支撑，直到毕常奇来了，6台，还是7台备份机，硬盘坏的是此起彼伏。 Log库，emp，还有王绪峰组,我忘记了业务线的名称了，暴涨到800G的数据，备份机坏了，再加上空间不足。我索性停了备份，最后只保证了ms，hp,tg,tc一些大库的备份，这个58同事接手后估计会被他们鄙视坏了。
这个其实后来华为32T的备份机来了以后，备份机制应该变通的，怪我
还有异机备份，每2个月 4个2T盘就会保存满了，更换，挪盘，手动做raid挂盘，手动excle做记录。最后还真有次要用到这些盘查找数据。
磁盘问题
Hp 俩个大表，需要定期清理数据。Ms 磁盘每天10G的增长速度，而且ms需要用pcie卡，最后终于可以从800 扩到1200。可以消停几个月。Ms 有几个台机器，最后就差10G 左右就要满了。各种删日志，各种挪数据，东墙补西墙，（搞的我知道400G 的ssd 做xfs 要比ext4 能省20G 的空间，刚刚好够给ms用），而且磁盘的增长，伴随着备份机，磁盘空间不足，sim机（提供只读服务给开发的我忘记叫什么了）空间不足。还有report库，想申请磁盘，服务器，机柜没有位置了，就那样挺着单库跑了很久。
还有就是王绪峰组 和tc 的 通过框架生成的sql
生成多余的子表，varchar 类型的字段条件不加单引，再加上上线建表不加索引，定期需要检查sql，进行优化。
痛苦的hp，主库拆分。
历时1年多，没有分拆完整 。最后听毕常奇说，瓜子二手车从这些库里拆分。自上而下，强行拆分。1-2天拆分了。
php的短连接，连接数满
这个最后的最后，你们走了后，偶尔在分析hp全日志，发现hp每1-2次连接，伴随着一次空连接。Connect 什么都不做 quit。这个问题不知道什么有的，改了后，hp的连接数问题好了。
总结，在赶集，因为数据的暴涨，只是一味的应对，没有快刀斩乱麻，进行分拆。还有就是有个dba的平台真是很必要，管理监控，提交审核sql，这个直到后来我才能够模仿着automan勉强写了个。
文章由php中文网网友泽润供稿，转载请注明，本文地址：//m.sbmmt.com/toutiao-352102.html
