DBA工作初体验之心惊胆战

前端时间刚换了工作,从5月16日开始,我正式成为了一名专职MySQL DBA(还在试用期),开始一段全新的体验。新就意味着有很多很多的工作要做,规范行为,整理思路,协调工作。回头一看一个月已经过去了,从之前没有写过SQL语句到现在平凡的数据统计、客服查询,一次次惊奇sql还可以这样那样,知道有那么多统计|时间|字符等各种有用的函数,开始一点点体会书本上学的索引在实际语句中的使用,是用表连接还是子查询,执行时间的快慢等等。

突然发现一个问题,感觉很明显,就是很多之前从书上学过了解到的知识,工作中并不会很自然地主动地被想起,而是每次就跟新东西一样,都是在同事的提示后,才恍然大悟,“哦,原来这样,其实,很早就知道这个东西的…..”,基本功不扎实呀!好比,渴了自然就会想到喝水。开始的自信与张扬已是消失殆尽,现在的心态就是:踏实、诚恳、谦虚地去学习,努力做好每件事情。

这一个月无论是工作的压力还是心情的波动,都让我体会颇多。第一次感觉到原来工作是有压力的,以及所背负的责任。我是一个很在意别人看法的人,我希望被每个人所认可,所以每次任务都积极去完成,但由于天生性格的急躁,还是总会弄出些岔子来。尽管开始成熟,但还是缺乏稳重。

下面就和大家抖露抖露我这一个月的“风花雪月”。

1. 头疼的SQL

任务:第一周领导就分配了统计需求的任务。将近20条语句以及数据导出弄了一周。说实话,现在对Tarot库还是一知半解,依然需要现查现看结构注释。

体会:SQL语句的组织并不是很难,刚开始一直被GROUP BY、COUNT()弄的很晕,写SQL是个熟练活,该用什么怎么实现也都很讲究技巧;而重要的是你需要对统计的这个系统本身有更多的了解,也就是业务流是什么,数据在各个表中是一个什么状态,是字典表、业务表还是日志型表,每个字段的确切含义。SQL对我来说几乎就是“零”,功能的实现目前来说都很吃力了,至于执行的性能,更是心有余而力不足,只能后期实际中遇到了再加以改进了。

2. 不小的事故

任务:每周二系统例行维护。对于数据库需要做的是,主库清除前一个月一周内的日志型表中的数据,并在从库进行全备。

体会:由于备份结束后,没有对北方区dump文件进行检查,dump文件只有4K,显然mysqldump出了问题(事实上,dump是正常结束的,困惑?),导致之前主库删除的数据丢失(因为我们的从库开启了log_slave_updates,binlog会记录同步过来所执行的sql语句)。在备份测试机上通过恢复4月的dump文件,将被清除的那一周数据导出,然后用从新做的新dump文件恢复后,将之前导出的数据重新导入到库中,最后在重新做一次全备,得到4.5G的dump文件,tail -n 1 dbname.sql结尾行正常“Dump Completed on …”(感谢realzyy提供的简单快捷的检查方法)。当初觉得,这些历史数据对应用本身并没有影响,只是为运营团队提供后期数据分析,反正已经成功回复,也没有太当回事,之后也没及时向领导汇报,后来领导找我谈话,我才深刻认识到问题的严重性,对于数据一定一定要格外加倍小心,无论是做什么用的,必须保证安全。经过这次风波后,做任何操作我都变得格外小心。做事情的条例很重要,开始的时候,哪怕慢点也要力求稳,不知道不清楚绝对不能操作;我们要知道获得一份信任需要很长的时间,但是让别人放弃你那是瞬间的事情。The first time is also the last time…Keep in mind…Be careful….Fish….我现在时刻背负着被开的风险,只能靠以后积极努力的工作去挽回失去的信任。

3. 完善备份

任务:定期全备与每日增量备份脚本的测试与修改。

体会:一周都在修改shell脚本,有脚本帮我们去完成重复性的操作既方便又可靠,但是脚本不是能实现你的工能就可以了,事实上,我们更想知道执行的结果正常与否,这就需要脚本能够收集这些信息并反馈给我们,所以要生成日志文件便于我们查看,或以邮件方式将报告发给我们。

关于mysqldump的参数选择,我最近体会颇深。之前写过一篇MySQL企业级备份与恢复,现在想下就是标题当,什么狗屁。 mysqldump什么参数都不加,一看就不专业。突然想起来之前去飞信面试,周师傅问我,mysqldump备份的时候加什么参数吗,我很自豪的回答,什么都不加呀,那个默认opt就很好了,现在想想脸红呀,差的不是一点。

mysqldump

4. 语句分析

任务:开发人员反应客服系统中一条SQL语句执行过长,导致系统超时报错,同时呢,还会导致主从复制不一致(Seconds_Behind_Master超过300秒nagios会报警)。

体会:这条语句是做分页的,每次显示50条记录,同时按时间排序,3个表(record_goods,goods,characters)做关联,其中一个是物品交易表(record_goods),有千万条记录,每次执行该条语句时,我在从库的服务器端show processlist\G去查看该条语句的执行状态,发现stat是locked,被锁住了,同时发现slave中的sql_thread线程也同时有一条update语句locked在那里,但是,惊奇的发现这个被锁的表,却是那3个表中的其中物品信息表(goods),然后我又show table status goods\G,发现该表竟是MyISAM的,而且那个update time时间在不停的更新。这下明白了,从库保持同步主库上goods表的update操作,这样就会对goods表叫锁,它又是MySIAM表,自然表级锁,当我们在执行那条查询语句时,如果执行时间过长,update操作就会被锁住,导致从库同步落后时长增加,导致nagois报警。之前提到,物品交易表非常庞大,后来我们采用自查询,先对record_goods表和characters表做表联接,查出符合条件间的50条记录,然后再将产生的结果集与goods表做关联查出最后系统所需的结果,执行时间不到1秒。我要从新更新我脑子里面之前那些经验性的总结,至于是表联接性能好,还是子查询性能好,实际中怎么好就怎么来吧。

这一个月的体会就是这么多了,下次再继续分享我的DBA初体验。

觉得文章有用?立即: 和朋友一起 共学习 共进步!

猜您喜欢

3 thoughts on “DBA工作初体验之心惊胆战

发表评论

电子邮件地址不会被公开。 必填项已用 * 标注

*

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>