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

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

海因里希法则"（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

#数据库 #运维 #巡检