一次宕机问题的总结复盘

这是学习笔记的第 2022 篇文章

昨天开了一个会,开完会刚打开电脑就收到了5条报警邮件,提示有4套环境发生了高可用切换,这是一套分布式集群环境,经过了长时间的测试,已经临近上线,因为业务的特殊性,出现了这样一个问题,着实让人尴尬。最开始看到这个问题的时候,是有些奇怪而且略带失望的,因为已经切换超过了2个小时,但是大家似乎都没有意识到这个问题。

因为这个问题还没有正式接入线上业务,所以咱不存在业务影响,但是通过这个问题发现存在着较大的隐患,而且按照这种态势下去,我们的系统迁移结果还是有很多不可控因素,所以早上和团队的同事进行了复盘。

首先简单说明了下这次复盘的主要目的,不是具体针对谁,而是把问题都跑出来,看看有什么好的方案加以解决。

问题的背景:一个分布式集群的4个节点出现了高可用切换,但是因为数据延迟过大,导致切换失败。

对这个问题的过程进行梳理发现,一方面是因为计划外操作导致磁盘空间溢出,另一方面是存在一些配置和监控报警不到位的情况,所以这个问题给我们敲响了警钟。

总体来说,我梳理了如下的一些问题:

  • 监控不到位
  • 报警不到位
  • 不熟悉系统架构
  • 不熟悉业务特点
  • 计划外操作的流程不规范
  • 高可用切换失败的隐患
  • 配置导致的空间隐患
  • 数据安全存在隐患

我来逐个展开一下。

  • 监控不到位,发现目前的集群监控是不完整的,存在一些监控盲点,需要细化和确认,保证监控的有效性。
  • 报警不到位,有些服务器有监控,但是没有配置报警选项,导致问题发生的时候产生了信息隔离。
  • 不熟悉系统架构,因为大部分的管理工作是我这边在做,一旦出现问题,熟悉系统架构的人少,难以形成有效的技术互备力量。
  • 不熟悉业务特点,对于业务不够了解,在问题发生的时候很难定位问题的瓶颈,需要结合业务特点和使用方式来进行综合评估。
  • 计划外操作的流程不规范,比如在集群中执行了负载较高的全表DML操作,会导致集群产生大量的日志。而敏感的操作缺少有效的管理,没有提前告知团队成员,在问题发生之后,也没有关注这个操作的影响范围。
  • 高可用切换失败的隐患,高可用切换失败一方面是因为数据延迟导致,同时需要检查是否已经删除了MHA自动生成的failover标志文件,如果存在,下次切换会失败,造成难以挽回的影响。
  • 配置导致的空间隐患,对于binlog的保留周期需要做定制化配置,比如从原来的7天修改为3天,配置从库为只读状态,避免不合理的写入影响
  • 数据安全存在隐患,目前的数据管理存在隐患,对于业务开放的权限需要做到可控和有效,不能开放过高的权限,避免数据误删除。需要配置一个权限较高的管理员账号方便管理。
  • 信息同步机制,一旦发生了数据切换,我们需要及时提醒业务方,让多方引起重视,而不是默默的处理。

所以上面的问题经过分析之后,发现我们在工作中确实存在着很多的不足和改进空间,而这些也是我们进行数据管理的一些基本规约,即什么该做,什么不该做,需要心中有数,而对于自己的操作需要做到公开透明,至少需要明白这个操作的风险和影响,减少意料之外的影响情况。

这个问题在这个阶段出现着实给我们敲响了警钟,而我们也不能以被动的故障来改进,而是逐步转变思路,变成更加公开透明的问题处理方式,在实际的问题处理中,做到对事不对人。

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

原文发表时间:2019-06-27

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

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券