前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >宕机的那些事儿(r12笔记第44天)

宕机的那些事儿(r12笔记第44天)

作者头像
jeanron100
发布2018-03-21 16:04:16
9640
发布2018-03-21 16:04:16
举报

DBA干了这么多年,一直以来有一个疑惑,那就是从半夜的电话中吵醒时,几乎清一色都是宕机类问题,每次我就忍不住想喊,大早上宕机,让不让人睡觉了。但是抱怨归抱怨,活得干,坑还是得补。这话对于很多DBA来说是感同身受,谁还没大半夜被电脑吵醒过,如果没有,你这DBA生活还真是滋润啊。

当然随着工作的经历增长,我想明白了几件事情,也感谢这些难忘的日日夜夜。

宕机能够刷到存在感

第一个是数据库宕机从技术角度之外有时候还是有一些作用的,那就是很多时候宕机之后大家会深刻感受到DBA的存在,而平素系统稳定了若干年,换谁都会认为这是一个可有可无的角色,直到业务中断,数据恢复迫在眉睫,DBA的重要性才会凸显出来,当然我们不能拿这个当做挡箭牌,毕竟在现在的云时代,如果宕机后有应用的重连机制,我们甚至可以会瞅一眼手机继续睡觉,因为数据恢复切换云上已经做好了。所以这一点上,我是中立态度。

宕机原因其实有一些规律可循

第二个是数据库宕机其实都是有一些规律可循的,为什么很多服务器都是大半夜的时候宕机,服务器和人不同,不需要在哪个时间点睡觉,一种很可能的原因就是服务器在那个时间点更加繁忙,为什么繁忙,因为这个时间点是我们认为的业务低峰期,所以很多事情都往这个时间点来安排。而各种批量备份导致IO,CPU使用率过高,各种批量任务导致系统的压力骤升,各种批量查询任务导致硬盘比平常要忙得多。这个宕机的风险自然就高了许多,而这一点很大程度上却合乎情理,不备份就要丢数据,不同步数据就会不一致,不批量处理很多数据就无法及时更新,所以这个工作原则上是必须的,但是在合理之外我们是否需要检查这些工作是否已经做得足够好。总体来说在业务低峰期,很可能是系统的一个小高峰,比杜甫还忙。

存在即合理,存在即不合理

有句哲语说得好,存在即合理,但是在宕机这个场景中得改一下,存在即不合理。因为宕机很可能是有很多不合理的现象导致,一旦存在这类很多不合理,资源不平衡的情况,宕机就是迟早的事情,而这一类的问题我碰到的尤其多。

我举一个简单的例子吧。这是一个数据库归档次数的图表,可以看到每天都有一个归档切换的小高峰,每个小时竟然能够达到50次左右,这对于一个很稳定的OLTP业务来说,是很不正常。

而问题的原因我们一层一层剥开,首先定位到是SQL的问题,是一个delete语句,每天清理前一天的数据,而这样的语句有好几个,也就意味着有多个这样的数据表都是这样的逻辑,而为什么要delete清理这些数据,其实我认真分析了一下,发现是开发的同学对分区表不了解,这个过程如果使用分区来处理,那就是秒秒钟即可搞定的事情。

我再举一个例子,那就是数据同步,很多时候我发现数据库的负载突然会升高,可能就几分钟,但是提升幅度是在太大,不得不让人关注,我发现很多的数据同步逻辑竟然都是全量,全量的逻辑就是清理“旧”数据,然后重新插入数据,对于千万级,亿级数据量的表来说,这个操作涉及的面极广,影响很大,改为增量之后,可以说分分钟即可搞定。

宕机中的“假”宕机

其实有时候会有宕机警报,其实是假宕机。大体可以分为两个方面来说,一方面是网络抖动,这个时候就会出现报警风暴。我们会迅速淹没在各种报警中。我估计很多做运维的同学心理承受能力都变强了。我如果看到一个宕机报警,会认真的等第二个,如果没有第二个,那就继续睡觉,如果有了,那我这觉也睡不着了,在牢骚中开始披着衣服跑客厅去。

我碰到的还有一些宕机报警是假宕机,主要原因是资源使用率太高,比如连接数过多,我们连一个ssh都放不下了。有时候系统压力过大,我们一个命令都没工夫返回。当然这种原因也是五花八门。常见的一类是业务中的连接风暴,一股脑儿上来很多连接,直接无法响应了。

宕机:服务器过保,服务器替换

这个问题是很多公司存在的一个伪命题。服务器过保了就该换,但是从节省成本来说,还不大愿意直接让服务器退役。于是乎这种现象就变得自然而然,导致过保了换新服务器还需要解释更多的理由,每次把我饿了要吃饭和服务器过保了要换新服务器这种类似的理由我得解释得冠冕堂皇,我都讨厌我自己这样的状态。

我记得有一年连续一个星期,每天有一台服务器宕机,我都快被折磨疯了,服务器宕机了换备机有,但是要新服务器这个比较麻烦。

然后一个鲜明的对比就是,经过不懈努力,替换了一大批的服务器之后,这些新服务器很长时间都没有出现过宕机问题,我们的生活幸福度大大提高了。

数据库中的蜘蛛网

其实让我说Oracle,我恨不得不要有DB link,因为有了这个对象,数据库之间会存在各种各样的关联关系,就好像复杂的蜘蛛网一样。

一个事务要经过多个节点,然后互相依赖,耦合度强到一台数据库宕机,另外的数据库跟着遭殃,立马陷入了等待,阻塞还有大量的资源阻塞之中。很可能资源就被打满了,然后相继倒下。

所以分布式事务本身是个好东西,但是不能用坏了。不能什么设计都一上来都是分布式,在数据架构中,有些数据集中式管理就是要好一些。

宕机后的窘态

宕机之后,如果准备不够充分,很可能有很多窘态。我就简单列举一二,

1.宕机了,V**不给力,有时候真想砸了电脑

2.宕机了发现服务器密码不对,或者服务器密码忘了。

3.让我从迷糊中惊醒的就是数据库宕机了,突然发现没有备份

4.宕机之后给领导,同事打电话,打不通电话,这时候就是个信心孤岛,切换,等待,切换,等待,切吧。

每次我抱怨大半夜宕机的时候,很多同学都是饱含着同情看着我,结果另外一个朋友一语道破天机:大半夜宕机,你就庆幸吧。

我说这朋友真不会说话,他慢慢悠悠的说:其实大半夜宕机的话,你还是庆幸吧,你试试大白天宕机。

是的,我记起来了,因为大白天宕机了,你额头的汗会更多。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2017-04-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
数据库
云数据库为企业提供了完善的关系型数据库、非关系型数据库、分析型数据库和数据库生态工具。您可以通过产品选择和组合搭建,轻松实现高可靠、高可用性、高性能等数据库需求。云数据库服务也可大幅减少您的运维工作量,更专注于业务发展,让企业一站式享受数据上云及分布式架构的技术红利!
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档