干货|上云了,如何保障云数据库的高可用?
责任共担模型
上云后他经历了什么?
-
后端模块批量重启,重启时需要从数据库加载业务数据,因并发重启且该请求为慢SQL(几十秒),云数据库负载快速升高,部分请求开始超时,然后请求失败的模块无限重试,导致云数据库负载过大而崩溃,依赖该数据库的其他业务也全部故障;
-
在短时间大量并发请求数据库,高峰期并发达到2200左右,导致数据库出现大量慢SQL,进而数据库性能急剧下降,多个业务页面展现变慢,性能退化明显;
-
批量创建的任务,其执行时间完全一致,系统在瞬间对数据库请求大量数据,连接数上涨,导致该数据库上的所有业务均发生故障;
-
一次秒杀活动,系统请求量剧增,峰值流量达到平时流量的30倍,远超之前预估流量。部分功能大量请求数据库,占满数据库链接,导致数据库崩溃,进而引起系统无法正常运行
-
其购买的安全扫描产品,对接口进行了空参数请求,而接口对于空参数请求进行了数据库的全表扫描,数据库压力飙升,陆续出现了慢SQL,数据库CPU使用率持续在100%,导致该数据库上的其他业务也全部故障;
-
某服务访问数据库错误导致响应下游请求合法用户列表的结果为空值,下游模块直接将所有用户的权限全部删除,导致系统完全不可用;
-
没有专职DBA,云数据库的变更直接交由研发自己执行,研发多次数据库修改出现异常,导致服务故障和数据丢失;
-
研发怀疑数据库性能恶化,因此就重启了数据库,重启期间,有一个模块请求数据库失败,就直接崩溃了;
-
在华南部署的一套业务系统,连到华北的数据库,导致系统的响应时间长期居高不下,原因是一个页面包含了非常多的数据库请求,单个请求延时增加40ms,但几十个请求串行执行,延时足足增加了2s以上。
故障原因分析
和京东云平台质量部的同学们对上述的Case进行分析后,我们总结了以下原因:
成都创新互联公司的客户来自各行各业,为了共同目标,我们在工作上密切配合,从创业型小企业到企事业单位,感谢他们对我们的要求,感谢他们从不同领域给我们带来的挑战,让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。专业领域包括网站设计制作、成都网站建设、电商网站开发、微信营销、系统平台开发。
慢SQL
常态下系统中存在很多慢SQL,其执行时间少则15s,多则60s以上,如果慢SQL的执行次数增加,必然导致云数据库压力上升,数据库连接被占用,处理其他请求的速率也慢了下来,直至连接数被耗光,导致服务异常,或者在连接数没耗光之前,就因为数据库CPU使用率100%而导致服务异常了。
高频SQL
高频SQL看似没有问题,但延时一旦增加或者网络抖动,高频SQL就可能变为较慢的SQL,基于其基础足够大,足以将系统拖垮。
复用
上面的多次故障都是因为某一个业务异常导致数据库故障后,影响到了数据库上的所有业务,这可能是源于期望降低运维复杂度,所以搞了一个最大规格数据库的原因,确实,所有业务共用一个数据库从管理角度肯定更简单。
读写未分离
上述的Case,大部分都是读请求导致的故障,突然间因为各种原因,导致请求上涨,而数据库实例只有一个,没有水平扩展,所以很容易被打挂。
数据库连接数设置不合理
从故障描述中可以看到,随便一个请求,都可以把数据库的并发连接数打到2000+以上,进而导致其他业务不可用,没有对不同业务进行合理的资源分配。
缺乏变更流程
研发直接到线上数据库中修改数据,修改错误的原因有表的名字错了,where条件错了,或者是对较大的表结构进行调整,操作前不在线下进行测试验证,操作前也不进行数据库备份,很容易导致重大事故。
权限管理混乱
多个CASE都是研发直接操作线上数据,这是权限管理混乱的表现,也是很危险的事情。试想,人人都能修改数据库,会有什么后果大家应该都很清楚。如果修改了和交易数据相关的数据,或者是删库跑路,那就麻烦了。
不限流
云平台质量部的建议
TOP-N的SQL限流
-
慢SQL,也就是执行耗时的TOP-N
- · SQL优化
- · 合理设置数据库连接数
- · 执行耗时超过1s的SQL直接kill(对于部分场景可以进行自定义,如同步任务,写SQL,重要性较高的SQL等)
- · SQL问题较多的账号进行紧急封禁
-
高频SQL,也就是执行频次的TOP-N
- · 通过业务层的缓存功能减少高频SQL
在京东云上,提供了性能优化的功能,可以查询到所有的慢SQL,一定要加以使用
最后提一句,一定要想办法在集群上实现自动化kill慢SQL的功能,而不要等遇到出问题后挨个找人来看能不能杀这些SQL,那就太晚了,经验值,一旦走到这个地步,故障时长起步40分钟。
隔离部署
读写分离
京东云的云数据库提供只读实例,需要利用好该特性。简单点就是新增几个只读实例将读请求进行迁移,复杂点,可以将不同业务类型的读请求分配到不同的只读实例上,利用隔离的特性将故障控制在较小的范围内,从而保障大部分功能的正常使用。
限流
数据备份
对数据库的任何修改和调整,都需要进行备份,以免发生上述朋友的问题。京东云提供了灵活的数据库备份管理功能,需要好好的使用起来。这个地方的重要性,就不赘述了。
数据库的监控
没上云之前,可能会有专门的DBA团队来对数据库进行监控,上云后,如果没有专职的DBA,那么业务运维团队就需要承担起这个责任来。下面是从京东云的监控中截取的几个关键指标,当然,还需要有对数据库功能的监控。在这点上,云平台质量部有较为丰富的经验,大家也可以参考《监控不到位,宕机两行泪》。
流程建立
三板斧
-
隔离部署&&读写分离,利用京东云的能力,可以快速搞定,所以放第一位;
-
TOP-N的SQL,找出来容易,优化则需要研发配合,因此放第二位,可以先从那些执行时间几十秒的SQL开始下手;
-
限流,或者在接入层进行,或者核心模块上进行开发,耗时略长,因此放第三位。
最后,感谢平台质量部的多个小伙伴一起群策群力完成的上述方案。
参考文献:
当前标题:干货|上云了,如何保障云数据库的高可用?
URL分享:http://azwzsj.com/article/pphcgj.html