|
《我在赶集网的三年DBA经验总结》要点：
本文介绍了我在赶集网的三年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通过平台上线后,稍微好点.
- 因为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勉强写了个.
作者：董泽润 （编辑：李大同）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
