Osheep

时光不回头,当下最重要。

数据库,你不要死!!!

《数据库,你不要死!!!》

前言

众所周知,数据库是一个互联网企业的核心,每个公司都恨不得像守护刚出生的婴儿一样守护着它。但就算是7*24小时监控着,数据库也可能会出现天灾,更不要提一些人祸了。今天就跟大家总结一下我们公司数据库遇到的一些问题。

存储 info 级日志坑

某一天,监控数据显示交易量忽高忽低,没有规律,重灾区是设置交易超时时间的某产品,交易出现大量失败,客户投诉严重。大家聚焦问题,执行代码回滚方案仍无法解决,同时观察数据库现象为事务突然停滞数秒,然后又恢复正常,无时间规律以此反复。DBA 排查存储日志也未见异常 error,同时协调 IBM 分析这些日志,最终反馈有个 info 级日志无规律报某块 disk miss,建议更换硬盘试试,结果更换后交易恢复正常,此故障被 IBM 收集入案例库。

总结:日常巡检不要放过任何细节,info 级别日志也可能是 error 级别,也可能是致命的

BUG 类高并发短小事务坑

某年考试集中报名,应用频繁出现繁忙,线程报警,导致交易时断时续。查看数据库端负载稍微偏高,事务量是平常的 4 倍多,分析事务量与交易量并不成正比,进一步排查发现执行频率最高的 SQL 达到每秒 2000 次以上。通过一个简单的银行字典查询,开发人员定位问题为此考试接口为定制代码,有多次重复查询 BUG。紧急修复后交易正常。

总结:优化核心交易事务,精简代码,严格控制代码质量

悲催的各种用尽坑

DBA 发现由于最初的设计原因,交易流水表 ID 使用的是 INT 类型的 sequence,这使得交易流水表 ID很快就会用尽并导致交易停止。于是排查类似的可能用尽的坑,发现数据库日志 SN 居然也能用尽,只有升级版本后才能解决此问题,再一看当前 SN 号一身冷汗,此时推算核心交易库将在半年后用尽 SN 进入只读模式,后果不堪设想。继续探坑又有新发现,LINUX 平台 ETX3 文件系统单文件最大只支持 2T,而线上已经有存到 1.5T。

总结:坑也是无穷无尽的,想不掉下去,那就积极主动探坑吧

半死不活的硬件故障坑

某日短信通知系统中断,电话应急处理过程中 NOC 反馈未发现任何数据库服务器有可用性报警,但开发反馈应用无法连接数据库,于是 DBA 尝试登录此服务器发现能 ping 通,但 ssh 无法连接。立刻登陆远控卡发现 RAID 卡报错导致系统 hang,执行数据库切换方案后,业务恢复正常。

总结:系统 hang 会导致 Agent 报警,数据无法推送到服务端。报警策略一定要配置采集数据超时时间,避免不能及时发现故障

交易事务中乱七八糟的其他调用坑

核心交易数据库事务应该是最简洁并且效率最高的 SQL,如果调用其它资源响应时间慢或无响应,会直接影响主线交易。此类操作应做异步处理,此坑已经埋了很多人。

总结:核心交易事务代码必须严格审查,重视不够必进坑

数据库不可用导致应用无法启动的坑

线上有一些非核心数据库,如归档库,只对外提供历史数据的查询,为节约硬件成本,此库可用性标准 999。偶然一次代码上线过程中,应用启动后 hang 住了,日志无任何输出,问题无从查起。而此时某台历史库正在维护,由此推断是否和数据库有关,查代码后发现果然如此,代码对于数据库异常未做任何处理,无 try catch。此问题如果在上线阶段发生,其后果将是灾难性的。

总结:日志输出一定要遵循软件设计原则,系统日志的缺失对于紧急问题定位是灾难性的

缺乏沟通的坑

某天晚上接到系统人员通知,数据库不可用,交易中断。接到通知后, DBA 检查数据库状态,发现数据库表空间处于不可用状态。通过检查数据文件和询问系统人员做过什么,得知系统人员维护系统,修改了数据文件的权限,导致数据库不可用。后修改数据文件权限,并前滚数据库,故障恢复。

总结:数据库设备任何变更,都要和 DBA 进行沟通确认,不起眼的失误会导致灾难的发生

总结

通过以上例子可以发现,一个小小的操作,都可能导致数据库崩溃,造成不可挽回的损失。希望大家一定要遵守各种规范,三思而后行,凡事多想一步。你的一小步,稳定一大步。让我们的运维人员有一个完美的夜生活!

点赞