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

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

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

宕机能够刷到存在感

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

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

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

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

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

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

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

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

宕机中的“假”宕机

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

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

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

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

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

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

数据库中的蜘蛛网

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

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

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

宕机后的窘态

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

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

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

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

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

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

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

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

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2017-04-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏阮一峰的网络日志

防止网页被嵌入框架的代码

最近,国内开始流行另一种流氓行为:使用框架(Frame),将你的网页嵌入它的网页中。 比如,有一家网站号称自己是"口碑聚合门户",提供全国各个网上论坛的精华内容...

33840
来自专栏BestSDK

程序员那些悲催的事儿——从错误中学习进步

image.png 在StakeOverflow上有这样一个贴子叫“Confessions of your worst WTF moment”(WTF就是Wh...

296100
来自专栏Spark学习技巧

浅谈数据分库分表之道

为什么讨论分库分表 在服务器后端技术人员的成长路线上,分片(Sharding)思想的理解和把握是绕不过去的门槛,而数据库分库分表可能是讲述拆分思想最好的教材,大...

37650
来自专栏架构师之路

这才是真正的表扩展方案

事情变得有意思了,上一篇花1小时撰写的“一分钟”文章,又引起了广泛的讨论,说明相关的技术大家感兴趣,挺好。第一次一篇技术文章的评论量过100,才知道原来“评论精...

48250
来自专栏MySQL

分库分表后如何部署上线?

不要惊讶,写这篇文章前,我特意去网上看了下分库分表的文章,很神奇的是,都在讲怎么进行分库分表,却不说分完以后,怎么部署上线的。这样在面试的时候就比较尴尬了。

31110
来自专栏镁客网

「产品」揭秘全球首款Android PC的奥秘

17030
来自专栏北京马哥教育

25台服务器怎样支撑世界第54大网站

摘要:同时使用Linux和Windows平台产品,大量使用静态的方法和类,Stack Overflow是个重度性能控。同时,取代横向扩展,他们坚持着纵向扩展思路...

77090
来自专栏逸鹏说道

.NET技术+25台服务器怎样支撑世界第54大网站

英文原文:StackOverflow Update: 560M Pageviews A Month, 25 Servers, And It's All Abou...

40270
来自专栏林喜东的专栏

你的账号安全吗?

账号安全无小事,近些年持续不断爆出的安全事件,有很多低级错误其实都是拥有一个健壮的账号体系可以避免的;多次听闻后曾写一写账号安全相关的东西,但直...

27740
来自专栏杨建荣的学习笔记

DBA和开发同事的代沟(二)(r7笔记第18天)

参考:DBA和开发同事的一些代沟(一)(r7笔记第17天) 有些朋友给我反馈了他们遇到的小故事,我后续再整理整理,看看有多少。 我还是继续来分享我这边碰到的一些...

33530

扫码关注云+社区

领取腾讯云代金券