节假日数据库安全告急!DBA专家透露的巡检秘诀竟然是...

2024-02-23 18:44:18 浏览数 (2)

图片由通义万相生成 一 前言

海因里希法则"(Heinrich's Law)

工业安全先驱H.W.海因里希(Herbert William Heinrich)在1930年代提出的关于工作场所事故和非致命伤害之间关系的理论。海因里希在其著作中提出,大约有88%的事故是由人的不安全行为引起的,10%是由不安全的机械或物理条件引起的,而余下的2%是不可避免的“Acts of God”。

此外,海因里希也提出了著名的"1-29-300法则": 即在一个致命事故发生之前,通常会有 29起 小事故和 300起 无伤害的近失事件。这个法则强调了预防小事故和近失事件的重要性,因为这些小事件可能是较大或更严重事故的先兆。

灰犀牛理论

灰犀牛理论是由全球政策专家米歇尔·渥克(Michele Wucker)提出,该理论指的是那些高概率、高影响力且具有明显迹象的风险,但是常常被决策者忽视,直到这些风险真正显现并触发危机。

与“黑天鹅”事件不同,黑天鹅是指那些不可预见、发生概率很低但影响巨大的突发事件,灰犀牛事件则是完全可以预见和避免的。灰犀牛理论强调人们往往对这些明显的危险视而不见,或者选择性忽略,直到问题成为不可避免的危机。

海因里希法则警示我们: 任何非致命性的错误都有可能累积成为致命的崩溃。而灰犀牛理论则提醒我们,显而易见的风险往往因为被忽视而转化为巨大的威胁。

借此,我们认识到假期临近前对数据库进行彻底巡检的重大必要性,以防止潜在的问题积累成不可挽回的损失,同时也尽可能的避免黑天鹅的故障风险。我们需要对数据库进行健康巡检,防范于未然。

二 数据库巡检

基于时间纬度数据库巡检可以分为

  1. 日常巡检,基于我们积累的运维经验和故障经验,形成数据库层的监控,比如主键溢出, 备份有效性验证,配置参数和内存中运行的参数是否一致, 主备参数是否一致等等
  2. 节前巡检,主要是应对各种长假,比如 五一,十一,春节等较长时间的假期,因为假期时间长,相关人员响应时间可能比较长,因此需要重点检查数据库空间增长情况,大表增长,日常存储空间等,避免假期时间长, 空间不足等需要扩容资源时,各方响应比较慢的情况。

基于操作方式,可以分为

  1. 手动巡检 (实例数比较少的情况下,通过手动命令执行相关检查)
  2. 工具巡检 使用开源或者自研工具辅助查看 实例的运行状态,收集相关数据,并做出判断。
  3. 平台巡检 (应对大规模实例比如数百,数千个实例) 能全访问收集实例运行状态数据,并根据阈值报警或者给出相关问题,风险的处理动作。

三 聊聊巡检内容

3.1 数据库层面
  1. 自增主键增速是否异常,int类型 70%, bigint 182亿亿,理论上 不会有啥问题,但是挡不住有可爱的开发同学手动写入一个非常大的值,造成bigint 自增主键溢出的风险。
  2. 大表,比如日志类型的表,经常删除的表空洞 ,是否要提前处理碎片
  3. 备份有效性验证, 有条件的可以对所有数据库 ,或者核心业务的数据库进行备份恢复验证,恢复好之后,查询其中的表
  4. 备份服务器的空间问题,备份存放空间增量会不会满?
  5. 数据库实例,尤其是日志流水型,账务,交易, 日志类的系统占用的空间增量在假期间是否会有暴涨的风险。需要提前归档数据,迁移实例。避免节假日产生不必要的变更。
  6. 主备库参数是否一致, 避免不一致造成异常切换之后出现意外情况,
  7. 实例运行时参数 和 my.cnf 参数文件中值是否一致,异常重启之后,部分运维时设置的参数改变导致非一致性预期,可能造成其他故障。
  8. 其实还有一个是统计信息,主备的统计信息是否一致,数据库切换之后 会带来不一样的执行计划,导致潜在的性能风险。
3.2 数据库生态相关机器

3.1环节是说的事数据库实例层面的巡检项目, 接下来主要是支撑大规模数据库运维的周边生态机器或者实例,比如

  1. 运维平台应用所在的机器的稳定性
  2. 高可用组件的机器 orch,mha,或者各个公司自研产品。
  3. 数据库实例的元数据库问题,这里云数据库的面临的问题会更大,类似监控的监控,要确保核心的元数据库运行时稳定。
  4. 平台定时调度任务组件,比如 celery
3.3 主机层面
  1. CPU 负载
  2. CPU 工作模式,最大性能?还是最省电模式,不同模式会带来不同的CPU 主频,进而影响 SQL 执行效率。
  3. 内存 是否使用过的 70% ?SWAP 参数是多少,各个机器上的值否统一?
  4. RAID 卡充放电问题,RAID 充电会到账 IO 策略降级为 WT 模式,造成性能问题,产生大量慢查询。
  5. 核心数据盘空间 是否足够, 这点和 数据库层的第5点类似。

四、值班安排

备份,冗余是我们处理数据库高可用时的常用操作,对于DBA 人员的"异地多活",我们也需要制定假期期间的值班表,确保每个时间段都有相应的技术人员在岗/oncall,处理可能出现的突发事件。

其实这里还有一个潜在的问题, 负责值班的人是否为被处理业务的DBA,如果不是,就需要DBA 在平时积累记录针对不同业务的标准处理方案,比如 库存秒杀场景可能需要关闭 死锁检测 ,设置事务锁超时时间等。

通过以上方面的巡检和准备,我们可以最大程度地降低数据库在假期期间出现的风险,确保数据的安全性和服务的可靠性。这样一来,不仅可以让数据库运行更加稳健,还可以让DBA和技术团队成员都能够安心地度过一个愉快的假期。

have a nice day

#数据库 #运维 #巡检

0 人点赞