总结下就是各种故障多,随时候命,需要处理,这些直到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勉强写了个.
作者:董泽润
(编辑:ASP站长网)
|