对于一个数据库管理者(DBA)而言,各类数据库故障的处理是其日常工作之一,但也是DBA最不希望出现的工作。本文尝试以DBA的角度对常见的数据库故障进行分类,介绍DBA面对故障时可能需要采取的处理方法。
逻辑故障
逻辑故障一般指人为数据误操作,例如对数据库中的数据进行误删误改误增,导致业务逻辑出现故障。对于数据库而言,逻辑故障是最常见,占据DBA日常工作最多的一种故障。正所谓系统最大的漏洞是人,再完善的架构,也无法完全杜绝操作者放飞自我。
应对逻辑故障,DBA的恢复手段大致有如下几种方式:
-
闪回查询/闪回表
数据量较小,故障发生时间较近时,Oracle/MySQL可以通过闪回查询的方式获得指定数据的过去版本,直接进行热恢复。耗时较低,操作复杂度不高——可精确查询到某时间点或scn号下该数据的状态,通过sql语句进行update操作,或直接flashback table即可。
其中需要注意的是,闪回查询无法跨越DDL操作。
【恢复用时:数分钟级别】
-
闪回数据库(Oracle)
由于闪回查询原理为借助undo表空间查询数据的历史版本,但undo表空间为循环使用的区域,仅根据参数UNDO_RETENTION保障短暂的可靠保存时间(默认900秒)。因此当逻辑故障涉及数据较多(一次删除修改直接导致undo表空间多次覆盖),或发现时间不够及时时, Oracle可通过闪回数据库的方式进行恢复。闪回数据库需要停止数据库实例,并且一旦决定闪回时间点,该时间点之后所有修改均被永久放弃。
【恢复用时:数小时级别】
-
MySQL Binlog Flashback(MySQL)
MySQL Binlog Flashback是MySQL特有工具,由阿里云高级数据库专家彭立勋实现并提交给MariaDB基金会。原理为获取binlog日志并反向生成操作日志进行恢复,如delete生成insert,update生成反向update等。该操作为热恢复,需要DBA严格查出每个误操作的日志号。同时,由于恢复原理为binlog反向操作,因此同样无法恢复DDL操作(如TRUNCATE TABLE)。
【处理用时:数小时级别】
-
Log Explorer for SQLServer(SQLServer)
Log Explorer for SQLServer是针对SQLServer的日志查询和恢复工具,原理与MySQL binlog flashback类似,即通过生成事务的逆向操作脚本进行数据恢复。同样无法恢复DDL操作。
【处理用时:数小时级别】
-
备份恢复
备份恢复是最传统也是最后的恢复手段。需要调用备份,应用备份,往往耗时最长。此恢复为不完全恢复,即恢复到故障出现前的某时间点。
备份恢复作为最后的恢复手段,却常常是中小规模企业DBA倾向使用的方法。相比各种日志反向操作工具,备份恢复显得更为可靠,操作复杂度也更低,DBA可以很方便地在非生产环境将数据库恢复出来,再获取想要的数据进行生产环境恢复。
但对于银行、保险等金融机构,DBA水平更高,对RTO要求更严苛,使用备份恢复往往作为最后的选择。
【处理用时:数小时-数日级别】
-
逻辑故障案例
【生产业务库后台误删除数据】
· 发生时间:2017年某工作日中午13时
· 修复时间:同日下午18时
· 修复用时:5小时
某生产业务库日志表按月分表,后台人员进行老日志表截断(TRUNCATE)释放表空间时,操作的表名出错导致删除了当月日志表信息。
TRUNCATE后无法使用闪回查询/闪回表的方式找回数据。数据库本身未配置fast_recovery_area,且生产库不方便停库。只能调用头一日备份加上现有归档日志,在测试库进行不完全恢复,恢复点设置到误操作前的scn。
整体操作不复杂,但调用备份恢复以及将误删除数据从测试库拷贝到生产库的过程均耗时较长。最终花费5小时时间恢复数据。(数据库数据量在1T之内)
软件故障
软件故障是囊括种类最多的多样性故障,从监听故障,文件系统空间撑爆,到软坏块,数据文件/日志文件丢失,配置文件/控制文件出错等等。一般来说,从数据库软件到操作系统本身的问题都可以归结为软件故障。软件故障的恢复难点不单单在于恢复手段,更在定位故障原因,因此非常考验DBA的经验和trouble shooting的能力。
-
非宕机临时故障
网络故障、文件系统空间不足、计算资源不足等。
临时故障往往会导致数据库性能下降甚至实例挂起,直到处理完成或获得足够资源后自动修复。此类故障一般会有明确告警信息,不需要太多DBA经验就足以判断故障原因,解决方案也较明确。但此类故障频繁发生时,往往需要进行资源整改。
【处理用时:数分钟级别】
-
非宕机持续故障
非系统表空间软坏块、非系统表空间数据文件丢失、归档损坏、其他数据库待优化项等。
非宕机持续故障往往会造成持续性能降低,或数据完整性缺失,导致前端业务受到影响。此类与临时故障的区别主要在于故障原因。临时故障症结主要来自资源不足,持续故障原因则比较复杂,可能来自文件丢失,文件损坏,不合理的归档日志清理流程,或错误的性能调优行为。
此类故障需要DBA拥有一定经验进行判断排除,且修复过程各异。一般来说,涉及文件丢失的情况,常常需要调用备份进行恢复,有时需要停止业务进行部分表空间offline的数据库热修复。而涉及调优时,可能需要涉及实例重启。
【处理用时:数小时-数日级别】
-
宕机故障
系统表空间软坏块、系统表空间数据文件丢失、在线日志文件丢失,控制文件丢失等。
宕机故障与非宕机持续故障的成因大部分重合,排查难度和修复方式也类似。如果数据库处于高可用架构中,则单一节点发生宕机故障并不会引起长时间业务问题,前端连接failover到健康节点后,宕机故障可以通过调用备份恢复的方式进行修复。
但需要注意的是,宕机修复后重新启动的数据库实例,将经历一段性能受限时期,如Oracle重新将热数据块和sql写入缓冲的过程等。
【处理用时:数小时-数日级别】
-
软件故障案例
【某增值业务库Patch后启动报错】
· 发生时间:2016年6月某工作日中午11时
· 修复时间:第二日下午15时
· 修复用时:故障后28小时,DBA到场1小时
Oracle RAC数据库打PSU累积补丁集后数据库服务出现问题。报错信息为文件权限出错。排查后发现打补丁过程存在误操作,导致$ORACLE_HOME/bin/oracle文件权限被改为775,缺失了调用权限,即rws被改为rwx,导致其他用户调用该工具时无法获得share memory使用权限等内容。chmod 6751后问题解决。
该问题原因属于常见错误,但由于是补丁后出问题,加上打补丁过程中出现告警信息,因此 trouble shooting方向一开始完全放在补丁上,未能第一时间锁定错误本身。
硬件故障往往是最严重的故障类型,所以也是各类高可用架构重点规避的故障类型。硬件故障主要包括存储故障,服务器故障,通讯故障(交换设备,存储设备)等。
硬件故障的排查和处理均有难度,因此往往伴随着巨大的时间消耗。
-
通信设备故障
通信设备或通信线路发生故障,表现为网络/存储通信变慢或中断。由于故障现象的可能原因很多,因此排查难度较高。通信故障虽然不会造成数据丢失,但对业务影响往往不小。所有硬件故障都无法由DBA角色单独确认,因此硬件故障往往需要数小时甚至数天时间才能排查清楚。
【排查用时:数小时级别】
【修复用时:数小时-数日级别】
-
服务器故障
计算节点出现硬件故障,一般会伴随服务器宕机。该故障可通过高可用架构规避,一般不会造成服务长时间中断。但非常考验监控系统的完备性。最后一个健康节点宕机后,才发现数据库之前长期处于单点运行,是中小型公司中经常出现的状况。
【排查用时:数分钟-数小时级别】
【修复用时:数小时-数日级别】
-
储存故障
与数据丢失紧密挂钩,是Oracle RAC等非分布式架构的致命故障。存储故障一般分为磁盘故障与控制器故障,后者不太常见。磁盘故障发生时,数据库一般会出现坏块告警,但由于读取该坏块的请求被执行时(比如每日备份),数据库才能发现坏块并告警,该故障往往存在一定延时性。
该故障发生后,备用的计算节点和备用存储,完备的备份集都是故障修复的必备条件。
【排查用时:数小时-数日级别】
【修复用时:数小时-数日级别】
-
硬件故障案例
【银行反欺诈平台数据库写入过慢】
· 发生时间:2019年某工作日下午5时
· 修复时间:同日晚12时
· 修复用时:7小时
该反欺诈平台以Oracle作为特征向量库和日志库,需要频繁读写。故障发生时反欺诈平台每秒交易处理数(TPS)显著降低,经过报错日志排查,认定为特征向量库读写等待过高导致。
进一步检查特征向量库,通过AWR报告推测,等待发生原因可能来自存储IO等待。
检查存储告警,未发现异常。
同步进行机房巡查,发现存储光纤存在接口松动情况。
插紧后故障现象消失。
其他难以归类的故障,例如操作系统BUG,数据库源生BUG,Patch带来的BUG,无法归类的internal error等。总而言之,就是各种疑难杂症。
-
排查耗时
排查难度高,如著名的ORA-600 internal error。经常出现在操作系统或数据库软件进行补丁升级、调优变更后。排查用时无法预估,往往需要通过查询官方文档进行调查。
-
影响程度
影响性能、数据库工具的使用、严重时也会造成数据库宕机或无法对外通讯的情况。
-
修复难度
修复该故障往往没有明确的解决方法,如果由补丁引起,则回滚补丁。其他BUG则需等待官方修复补丁放出。所以DBA对于数据库版本升级和打补丁都采取较为保守的态度,一般会等待某个版本或PSU经过足够时间考验,确认稳定后才愿意使用。
-
其他故障案例