赶集网三年 DBA 总结
<p>2012年初入职赶集,当时处在流量讯猛增长的阶段,3年DBA生涯收获坡多,其实坑更多(泪... 后来在做开发时,慢慢体会到 ”运维“ 和 “开发” 确实存在沟通问题:知识不对称。如何解决呢?先总结下这三年吧</p> <p><strong>DBA职责</strong></p> <p>市面上招聘 JD 一大堆,随变找几个,马上能找出共性</p> <ul> <li>数据库系统的规划、设计、管理、迁移</li> <li>数据库的日常维护、备份、优化及恢复</li> <li>Master-Slave架构搭建、维护</li> <li>业务系统上线支持,数据库设计评审,提供架构方案</li> </ul> <p>数据库不局限于 MySQL, Oracle, 如果分的不细,还会有 Redis, MongoDB 等一系列 NoSQL。工作内容都一样,首先是高可用稳定性,不能今天抖动明天宕机,涉及工作很多。第二个是数据安全,比如备份及恢复,14年赶集审计,移动端的活跃用户数就是从备份中恢复来的,可见备份的有效性是重中之重。最后一个当然是为业务服务,对接业务需求,不能因个人生活被打断就罢工,有一次刚看电影就被叫回去处理DB报警,骂娘的心都有了。</p> <p><strong>悲惨案例</strong></p> <p>先举一些悲惨案例,让看官们高兴一下~ 由于公司早就不在了,这里没有顾忌。</p> <p><strong>1. delete 删全表</strong></p> <p>二手车同学的锅,SQL 拼错不带 where 条件,编写线下脚本时出错... 最后DBA根据 row binlog 恢复。至少2次:(</p> <p>反思:rd 新手一茬又一茬,规范讲再多也没用。最彻底的解决方式只有一个,接入 proxy, 限制一切非法 sql。另外 rd 上线验证也不到位,代码 review 肯定有缺失</p> <p><strong>2. 大卖家问题</strong></p> <p>房产在14年开通免费端口,短短几个月时间房产商业表爆涨到 100G,个别中介帐号发贴超过10W,导致数据库异常抖动,威哥临时清理过多发贴记录解决。最后耗时三个月对这张表进行瘦身,拆分 text 字段。</p> <p>反思:DBA 对大表监控不足</p> <p><strong>3. 大量子查询打跨主库</strong></p> <p>主站主库有一次被子查询打跨,事后排查,由于 RD 大量子查询导致。此类问题不是个案,有很多 RD 把本本该读 slave 的请求写到 master 上,只不过没有引起事故而已</p> <p>反思:赶集 DB 典型 1 主 N 从,没有 proxy 保护的怀况下,经常出现此类问题,只靠规范制度基本解决不了</p> <p><strong>4. 报表 olap 库问题</strong></p> <p>RP 库我和文武背锅,年底的绩效垫底。文武接手前的 RD 一个人开发中介商家报表系统,所有计算都是基于 DB,当免费端口开放后数据量爆涨,MyISAM 读写锁导致大量请求阻塞,听说公司因为报表连续问题赔商家300W。</p> <p>反思:这个事故得站在高处去看,免费端口开放太突然,项目技术负责人考滤不全。报表系统没有经过设计,完全由一个新人RD去搞,也就大学毕设水平,回头再看,hadoop spark 完全搞定。最后 DBA 没有及时对大表进行跟踪,没有提前发现。</p> <p><strong>5. 50G的Redis</strong></p> <p>房产业务 Redis 眼看从 20G 爆涨到 50G,我离开后也一直没优化掉。后来某次故障,数据清空了?</p> <p><strong>我的工作</strong></p> <p>大部份时间和开发沟通感情聊人生,后来 automan 上线很少有人找我了~ 每个阶段都有成长,都有感谢的人和事,赶集让我有平台去做感兴趣的事,很开心。</p> <p>刚到赶集时,SQL 上线还走的 jira,半自动化由运维开发同学做的,经常在技术大群里被艾特,很简单的建表或是DML 都要由 DBA 人工介入,很烦索。另外很多建表语句不规范,打回让 RD 修改,他们对此很有意见,认为无所谓的修改,这就在 RD和 DBA之间产生了沟通成本,诗展在的时候还会定期做数据库开发培训,然后就没有然后了。</p> <p>14年中着手 automan 平台开发,从前台页面到后端消息队列,到 sql parser 解析,从无到有,在刘军先河同学的帮助下最终上线完成。由平台去审核开发的 SQL,经过 sim 模拟环境,再到线上自动执行备份,比人工高效的多。</p> <p>这个系统原理和市面上其它工具差不多,扔有很大改进的地方。后来在数据库大会分享了一次,诚惶诚恐没有被喷。</p> <p>DBA 心得</p> <ul> <li> <p>夯实基础:DB 的基础自然是稳定,稳定,再稳定。实例数一多,基本每天都会遇到各种故障。主挂了就用 MHA 切换(最新的有gtid),slave 挂掉就由 lvs 自动摘掉读流量。还有一个就是备份,全量增量,定期备份有效性检测,每一块都需要人力的投入。</p> </li> <li> <p>硬件优先:DB扩容有 scale up 和 scale out 两种,一般优先堆硬件。buffer 不够加内存,128G 不够就 192G,磁盘阵列卡性能不行就上 SSD,再不行就上 flash 板卡。总之优先考滤硬件,争取架构优化的时间。</p> </li> <li> <p>未雨绸缪:慢 SQL 优化,定期出报表让 RD 调优,一般出问题都是索引没加,99%的大SQL都是这样,少部份因为表设计不合理(没有自增主键,或是频烦修改)。大表监控,该瘦身的瘦身,字段该拆的拆,横竖两刀,过期数据定期归档,基本上就这些事。</p> </li> <li> <p>结合业务:有些优化 DBA 累的半死,不如 RD 修改一行代码。DBA 也要多和业务接触,了解业务实现,不求给业务贡献多少,不背锅就好... 开玩笑。了解业务,就能站在更高的角度去思考,很有意义。</p> </li> <li> <p>学会拒绝:这个拒绝不是罢工不干活,而是要分清哪些需求的合理性与紧急性,不合理也不紧急的直接干掉,紧急但不合理的可以临时通过,快速解决问题,事后再确掉也可以。比如 olap 跑在了线上库,count(*) 计数 SQL 完全可以异步走计数器,Redis 是好东西。</p> </li> <li> <p>学会沟通:工作也有些年头了,这一点仍然在学习,也犯过不少错。沟通好权责,定下时间表。</p> </li> <li> <p>踏实学习:回头看当年DBA做的不够好,有些原因在于没有开发能力,很多想法止步于此。运维人员一定要有开发功力,并且要比业务 RD 更精,才能做好运维。</p> </li> </ul> <p><strong>运维RD的矛与盾</strong></p> <p>KPI 不同,关注点自然也不同,一线的同学经验也都有欠缺,特别是刚工作1~2年的,造成了信息与知识的不对称。解决这个问题也不难:</p> <ul> <li>新人要有导师带,对新人放手不管最不负责。这方面感觉 nice 做的不错。该夸还是要夸的。</li> <li>支撑团队要有足够的 wiki 业务文档说明。</li> <li>自动化用技术来约束,而不是人工。同比业务接口强约束,现在服务化都用 thrift 了。</li> </ul> <p>对赶集的记忆已经越来越模糊了,唯有...</p> <p>总结写了一部份后,原同事都说遗漏了一些,那就一齐追加到后面,版权不归我:)</p> <p>20170214 下面内容来自原同事: 李瑞</p> <p>回忆下赶集的dba生活</p> <p>总结下就是各种故障多,随时候命,需要处理,这些直到automan出来,强制rd通过平台上线后,稍微好点。</p> <ol> <li> <p>因为raid0的问题,至少遇到4-5次master硬盘的问题,需要紧急处理。</p> <p>tg 遇到1次,ms 切过次,貌似也是磁盘的问题。</p> <p>其他slave 备份机,硬盘出故障更是多,最多一周需要处理4起磁盘的问题。而赶集的mysqldb 普遍都大至少100G,数据报表库的磁盘有2.3T,没法通过备份的方式重架从库,我用了2-3周才搞定</p> </li> <li> <p>im 的swap 问题</p> <p>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是最后也没解决。</p> </li> <li> <p>备份</p> <p>备份的问题,1是磁盘空间的问题,1个还是raid0的问题。。</p> <p>最后你们走后,有1个月我独立支撑,直到毕常奇来了,6台,还是7台备份机,硬盘坏的是此起彼伏。 Log库,emp,还有王绪峰组,我忘记了业务线的名称了,暴涨到800G的数据,备份机坏了,再加上空间不足。我索性停了备份,最后只保证了ms,hp,tg,tc一些大库的备份,这个58同事接手后估计会被他们鄙视坏了。</p> <p>这个其实后来华为32T的备份机来了以后,备份机制应该变通的,怪我</p> <p>还有异机备份,每2个月 4个2T盘就会保存满了,更换,挪盘,手动做raid挂盘,手动excle做记录。最后还真有次要用到这些盘查找数据。</p> </li> <li> <p>磁盘问题</p> <p>Hp 俩个大表,需要定期清理数据。Ms 磁盘每天10G的增长速度,而且ms需要用pcie卡,最后终于可以从800 扩到1200。可以消停几个月。Ms 有几个台机器,最后就差10G 左右就要满了。各种删日志,各种挪数据,东墙补西墙,(搞的我知道400G 的ssd 做xfs 要比ext4 能省20G 的空间,刚刚好够给ms用),而且磁盘的增长,伴随着备份机,磁盘空间不足,sim机(提供只读服务给开发的我忘记叫什么了)空间不足。还有report库,想申请磁盘,服务器,机柜没有位置了,就那样挺着单库跑了很久。</p> </li> <li> <p>还有就是王绪峰组 和tc 的 通过框架生成的sql</p> <p>生成多余的子表,varchar 类型的字段条件不加单引,再加上上线建表不加索引,定期需要检查sql,进行优化。</p> </li> <li>痛苦的hp,主库拆分。<br> 历时1年多,没有分拆完整 。最后听毕常奇说,瓜子二手车从这些库里拆分。自上而下,强行拆分。1-2天拆分了。</li> <li>php的短连接,连接数满<br> 这个最后的最后,你们走了后,偶尔在分析hp全日志,发现hp每1-2次连接,伴随着一次空连接。Connect 什么都不做 quit。这个问题不知道什么有的,改了后,hp的连接数问题好了。</li> </ol> <p>总结,在赶集,因为数据的暴涨,只是一味的应对,没有快刀斩乱麻,进行分拆。还有就是有个dba的平台真是很必要,管理监控,提交审核sql,这个直到后来在完美一天的时候我才能够模仿着automan勉强写了个。</p> <p> </p> <p>来自:http://www.jianshu.com/p/58962c334a35</p> <p> </p>
本文由用户 KarPokorny 自行上传分享,仅供网友学习交流。所有权归原作者,若您的权利被侵害,请联系管理员。
转载本站原创文章,请注明出处,并保留原始链接、图片水印。
本站是一个以用户分享为主的开源技术平台,欢迎各类分享!