fio压测导致Oracle主备库与备份连环故障的复盘与恢复实战-北京尧图网络

那天下午客户那边打着电话过来声音都是抖的核心库挂了备库断了一大截备份也没跑成功。我登录上去一看告警日志里全是log file sync、log file parallel write的超时等待主机load飙到四五百存储的IO util直接顶在100%。再一查进程有一台机器上正跑着几个fio参数是典型的随机写压测正好打在数据库的数据卷所在的LUN上。这就是一次非常典型的“国产信创环境下fio压测把主备库和备份链路一起搞瘫”的事故。这类问题在信创项目里一点都不罕见。信创环境本身硬件、操作系统、数据库还有存储的磨合期就长再加上压测这类操作经常由基础设施或者第三方测试团队来执行和数据库团队之间的信息同步往往不到位一旦fio这种猛药下错了地方轻则数据库卡顿重则实例重启、Data Guard断档、备份集损坏一起找上门。这篇文章我按实际处理顺序复盘一下整个经过从第一个告警开始讲到主库恢复、备库重建、备份故障处理最后总结几条信创环境下压测红线。内容会比较长但每一步都是能直接落地执行的东西。1. 事故现场与第一反应1.1 从一条告警短信说起当时环境是这样的某客户核心交易系统数据库用的Oracle 19c RAC加单实例Data Guard物理备库操作系统是麒麟V10服务器是国产芯片存储走的是多路径映射的分布式存储。数据库归档频繁RMAN每天晚上做增量备份加归档日志备份周末做全量。这套架构本身跑了大半年一直很稳谁也想不到最后栽在fio手里。告警短信是下午两点多开始刷的先是主机CPU和load升高接着数据库实例出现“ORA-27300系列”的进程异常信息再往后就是经典的“Log file sync”等待事件大面积堆积。登录服务器第一眼iostat里面%util已经是100%svctm从平时的零点几毫秒跳到了几十毫秒avgqu-sz高得离谱。同时在ps进程列表里发现了几个可疑进程fio配合参数里醒目的randwrite、iodepth 64、numjobs 4压测对象是/dev/mapper下的一个多路径设备后面lsblk一看这个设备正好映射到数据库数据文件所在的文件系统。再配合告警日志看从14:00开始主库的LGWR进程就一直处于等待状态日志切换被卡住最终导致所有需要写Redo的事务全部排队。这个状态持续了大概十几分钟集群软件那边认为实例无响应直接触发了节点的eviction流程实例一次性crash。备库那边也因为找不到连续的归档日志MRP进程自动终止Data Guard中断。更巧的是当时RMAN正好在做增量备份备份写到一半目标备份集所在路径同样挂在被打满的存储上于是备份片没能正常写完RMAN直接报错退出。1.2 现场信息收集清单遇到这种场面第一步千万不要急着去启动数据库或者重建备库先把现场信息固定下来否则后面全是猜。我一般按下面这个顺序收集操作系统层uptime、top、iostat -x 1、ps -ef | grep fio、multipath -ll确认fio进程的压测范围和当前IO状态。数据库告警日志$ORACLE_BASE/diag/rdbms/xxx/xxx/trace/alert_xxx.log重点看从第一个异常到实例crash之间的内容。Data Guard日志备库的alert日志以及v$dataguard_stats确认gap到底拉到了多大归档文件缺了哪些。RMAN相关如果使用恢复目录先查catalog否则查控制文件里的备份信息标记哪些备份集是invalid状态。文件系统/存储状态df -h、dmesg、存储侧的管理界面确认是否有磁盘报错或者多路径切换的记录。当时收集完这些基本可以确认这是一场“IO层面的雪崩事故”。主库和备库以及备份走的存储是同一套底层资源池fio把存储的IO能力耗尽后数据库、归档、备份全部受影响谁都没有幸免。2. 为什么fio能把数据库“打”到起不来2.1 fio压测的“正确姿势”和“要命姿势”fio本身是一个非常优秀的IO性能测试工具本身没有任何问题。正规的做法是存储团队用它直接对存储LUN做压测测的是存储设备的极限能力一般在业务空闲窗口执行而且不会在生产主机上直接跑。跑的时候通常使用独立的压测服务器或者用一台不承载业务的计算节点配合专门的测试存储卷所有测试参数都有清晰记录测试完成后立刻清理环境。“要命姿势”则是直接在数据库主机上跑fio尤其还是root用户执行并且压测目标恰好就是数据库的文件系统。这种事情在信创项目里不是个例。为什么因为信创环境经常要补各种测试报告存储性能、服务器性能、数据库性能都要验证。测试团队为了图方便拿着fio就往生产机器上一塞随便写个路径就开始压根本不关心这个路径背后连的是哪块存储、和什么业务共享。fio一旦以libaio引擎、大iodepth、多numjobs的配置跑起来IO请求会以极快的速度打满整个存储控制器的队列。这个时候数据库的每次IO哪怕只是一个4KB的Redo写都会被排在几百上千个测试IO后面延迟从毫秒级变成秒级甚至分钟级。数据库是最怕IO延迟抖动的尤其是写Redo的路径一旦慢了全库所有提交都会被拖住连接数迅速堆满应用雪崩式报错。2.2 主库故障链路拆解从数据库内部看这场事故的等待事件链条非常典型存储IO被打满LGWR无法快速写入Redo。所有事务提交时等待“log file sync”这个等待事件的持续时间直线上升。LGWR在等待Redo写入时又持续触发“log file parallel write”超时。日志写不进去日志切换也无法完成Checkpoint卡住。最终造成数据库出现“Log file switch”相关等待以及实例内部进程被卡死。集群健康检查认为该实例无响应触发节点驱逐实例crash。如果fio压测过程中碰巧有日志组正处于写一半的状态就更麻烦。当时的告警日志里就出现了ORA-00313: unable to open next log for member和ORA-00312: online log无法读取的报错这意味着某个在线日志组成员在IO异常状态下没能完整写入重新启动时会直接被判定为损坏。日志组一旦坏了主库能否顺利拉起来都成问题更别说后面的Data Guard和备份了。数据库实例crash本身不可怕可怕的是它在crash前把一些关键文件状态搞成了不确定。比如当时的在线日志组处于“需要归档但归档失败”的状态这个状态如果不清掉数据库就是死锁状态想启动都启动不了。2.3 备库断档与备份中断的连带效应主库已经卡成这个样子备库自然好不到哪去。Data Guard的原理是主库写完Online Redo Log后由归档进程或者LGWR直接同步传送到备库。主库日志切换跟不上备库拿不到日志gap自然越拉越大。更惨的是当时主库的归档目录也是挂在同一套存储上归档日志本身就没写完整相当于给了备库一份残缺数据备库的MRP进程尝试应用时直接报了日志文件不存在或者无法读取然后自动停掉。比起主库crash备库断档其实更让人头疼因为这意味着如果主库真的起不来了整个系统连一个勉强可用的容灾副本都没有。RMAN那边也是因为存储被压满备份片写入超时最终报错退出控制文件里留下了一个损坏的备份集记录。至此主库、备库、备份三条线全部异常属于典型的“连环事故”。3. 主备库与备份故障的处理顺序3.1 第一步止损与确认恢复条件任何故障处理第一步永远是止损。当时我第一时间让现场同事kill掉所有fio进程然后确认fio的压测对象是否已经和数据文件、归档目录、备份目录完全隔离。如果存储队列还处于满载状态就算kill掉进程也要等几分钟让队列里的IO排空。在确认存储IO恢复正常后再开始做数据库的恢复。这个顺序很重要不要数据库还没恢复之前又去重启存储或者做多路径切换弄不好会把本来没问题的事情搞成二次伤害。确认恢复条件一般看三点存储IO是否恢复正常iostat观察10分钟确认%util稳定、svctm回落。主库的所有数据文件、控制文件、日志文件是否可以正常读取。备份目录、归档目录是否可写建议先touch一个测试文件验证。3.2 第二步恢复主库处理Redo损坏主库的alert日志里出现了ORA-00313这就说明在线日志组中至少有一组日志无法正常打开。遇到这种情况先不要直接尝试startup要先通过v$log来确认是哪些日志组有问题以及这些日志组的状态。select group#, sequence#, status, archived, bytes/1024/1024 mb from v$log order by group#;如果损坏的是非当前日志组且已经被归档过了那处理起来相对简单直接清空这个日志组即可alter database clear logfile group 3;如果遇到被标记为需要归档但当前没有归档文件的情况或者clear的时候提示日志组里有未归档的redo可能需要额外使用alter database clear unarchived logfile group 3;这样做有一定的数据风险因为会被强制标记为已清除且不再要求归档但如果不清理数据库连启动都做不到。具体场景要具体判断如果损坏的是当前日志组或者包含了当前SCN关键信息的日志组那就不能靠简单clear了而是需要做基于SCN的不完全恢复甚至可能需要联系专业恢复团队介入用底层扫描工具来挖掘信息。当时我们运气还行损坏的是历史日志组所以直接clear之后主库就能正常启动了。这里补充一句信创环境下的Oracle跑的是国产芯片和国产操作系统很多以前没见过的怪现象都有可能出现。比如日志文件状态和实际磁盘状态不一致、ASM实例无法正常启动、多路径设备识别延迟等等。处理时要耐心不要用惯性思维套用原来x86环境下的经验一切以日志为准。3.3 第三步备库重建gap过大直接做duplicate主库起来之后紧接着处理备库。备库当时的gap已经远远超出了自动补归档的范围补日志这条路基本走不通这时候我直接放弃了修复gap的思路改为重建备库。Oracle Data Guard备库重建最稳的方式是RMAN的duplicate target database for standby from active database也就是从主库在线拉一个完整的备库出来。这个方式的优点是不需要提前把主库停掉也不影响主库正常对外服务而且整个过程RMAN会自动完成文件传输、参数配置和日志应用恢复。具体步骤如下确保主库处于归档模式开启强制日志和Data Guard相关参数。alter system set force_loggingtrue scopeboth; alter system set db_unique_namePRIMARY scopespfile; alter system set log_archive_configdg_config(PRIMARY,STANDBY); alter system set log_archive_dest_2serviceSTANDBY LGWR ASYNC valid_for(online_logfiles,primary_role) db_unique_nameSTANDBY; alter system set log_archive_dest_state_2enable scopeboth; alter system set fal_serverSTANDBY scopeboth; alter system set standby_file_managementauto scopeboth;备库主机上配置好tnsnames保证主备互连正常测试tnsping通。准备备库的参数文件指定db_name、db_unique_name、control_files、db_file_name_convert、log_file_name_convert等关键参数。执行duplicate命令rman target sysPRIMARY auxiliary sysSTANDBY在RMAN中执行duplicate target database for standby from active database spfile parameter_value_convert PRIMARY,STANDBY set db_unique_nameSTANDBY set db_file_name_convertDATA/PRIMARY,DATA/STANDBY set log_file_name_convertDATA/PRIMARY,DATA/STANDBY set control_filesDATA/STANDBY/CONTROLFILE/control01.ctl nofilenamecheck;等duplicate跑完把备库切到恢复模式alter database recover managed standby database using current logfile disconnect from session;通过v$dataguard_stats确认主备日志同步状态select name, value, unit from v$dataguard_stats where name in (transport lag,apply lag,estimated failover time);备库重建整个过程大概用了不到一个小时这里也提一下为什么不用从旧备份restore的方案。如果说之前RMAN的备份没有坏那从备份恢复再补归档也是可以的但当时的备份集已经损坏靠一个损坏的备份集去搭备库根本不现实反而会增加变数。from active database虽然会对主库有一定的IO压力把整个数据文件通过网络传输一遍但胜在干净、可控、无残留是故障恢复场景下最优先的方案。3.4 第四步修复备份链路重建RMAN备份基础备库恢复同步之后最后处理备份故障。当时RMAN的备份链路有两个问题一个是备份片文件的物理损坏另一个是控制文件里记录的备份信息不可信。首先处理失效备份集。用RMAN连接到目标库查看当前有哪些备份集是损坏或者过期的RMAN list backup summary; RMAN list backup corrupt;如果确认某个备份集损坏直接删除RMAN delete force backupset 12345;如果控制文件里的备份记录和物理文件不一致可以用catalog重新扫描备份目录RMAN catalog start with /backup/orcl/;这里要提醒一点如果损坏的备份集是0级全备而且当前没有其他全备存在别急着全部清掉先看有没有备库可以兜底。如果备库已经恢复正常那旧的全备其实已经不需要了直接清理掉重新做一次全备更省心。清理完失效备份集后重新建立备份策略。我当时的做法是先做一次全量备份然后马上做一次归档日志备份以防中途再有意外。RMAN backup database plus archivelog delete input; RMAN backup current controlfile;备份完成后还要验证一下备份的可恢复性这个很多人会忽略。备份链路恢复的判断标准不只是“能跑一个RMAN backup”而是“RMAN restore之后库能起来”。阿里当年有个名言叫什么来着“没有验证过的备份等于没有备份”这句话在信创环境下尤其重要。所以全备结束后我额外做了一次restore validate确认备份片可以被完整读取没有损坏和缺失才把备份链路这个故障正式关闭。4. 复盘哪些环节本可以避免4.1 压测对象、时间、方式的“三不碰”这次事故如果要说责任其实很清楚压测没做风险评估。fio压测本身没有错错的是把它跑在了生产数据库主机上还是对着数据库数据文件所在的存储LUN打。这里总结出来就是“三个不碰”适合贴在任何信创压测规范的第一页不碰正在提供服务的数据库主机。不碰数据库数据文件、在线日志、控制文件、归档目录所在的存储设备。不碰业务高峰时段。我有一次见过比较专业的压测团队他们做存储性能测试用的是单独的压测服务器连的是备用存储节点上的测试LUN压测产生的数据文件全部放在测试目录跑完直接清理整个过程和数据库环境零交集。这才是压测该有的样子。如果非要在数据库主机上做有限度的IO测试也一定要做到两点一是使用cgroup或者ionice限制IO权限和带宽不给fio无限制的IO能力二是压测文件必须放在一个临时创建的文件系统中与数据库文件的存储路径物理隔离而不是简单建立一个新目录就完事。4.2 信创环境下的额外注意事项信创和传统x86环境最大的区别是硬件驱动、操作系统补丁、数据库补丁之间的兼容性问题更多。比如有的信创服务器默认的开源fio包和老版本glibc不兼容有些系统要手动编译安装这时候容易引入很多不规范操作最常见的是直接到网上下一个编译好的rpm包安上去从来不验证这个包和当前内核模块是否匹配。还有一个容易被忽略的点信创环境的多路径配置五花八门。有的项目用的device-mapper-multipath有的用厂商自带的多路径软件还有的是通过存储厂商的插件接进来的。fio测试如果打在dm设备上还好说如果直接打到底层裸设备或者通过非标准路径访问有可能会触发多路径的路径切换逻辑造成原本正常的链路被重置那对数据库来说又是一次IO中断。另外信创操作系统的fio安装路径各不相同SUSE12上可能没有现成的fio包麒麟环境一般有现成的如果是欧拉系统又要走另一套安装流程。这些问题看似小但一旦处理不当压测人员就会自己手动编译或者改系统源反而埋下更大的隐患。4.3 团队流程与旁路保护技术问题背后一定是管理问题。这次事故要从流程上杜绝需要做到三点压测必须走变更审批流程DBA必须参与评审。压测方案必须写明测试工具、压测路径、压测时间、影响范围、回退方案。压测前必须对生产数据库做RMAN备份并在压测结束后检查主备同步状态和备份状态。如果条件允许最好在压测期间暂停RMAN备份任务避开和数据库维护窗口的冲突。这次事故最糟的地方在于备份恰好和压测撞上两者叠加直接破坏了备份集否则备份链路大概率是可以幸存的。类似这种“多个后台任务同时跑”的场景在信创项目里尤其要注意因为存储资源池本来就是共享的互相影响的可能性比物理机时代大得多。5. 常见问题与排查技巧实录这部分整理了一些在处理类似事故时经常被问到的具体问题和排查思路做成一份速查表方便以后遇到同类问题的时候对照着处理。故障现象可能原因处理思路主库大量log file sync等待实例卡顿存储IO被打满LGWR无法快速写入Redo检查是否有fio等压测进程停掉压测观察IO恢复情况数据库实例crash后启动报ORA-00313/ORA-00312Redo日志组文件损坏或未完整写入查询v$log判断损坏日志组状态非当前组可尝试clear当前组需做不完全恢复备库MRP进程停止gap过大主库日志中断归档缺失如果gap可补齐则通过fetch archive补gap过大直接重建备库备库无法应用某个归档日志归档日志文件在写入过程中被中断删除损坏归档从主库重新归档或通过RMAN重新备份恢复RMAN备份片损坏无法还原备份期间存储IO异常或实例crashdelete force删除损坏备份集重新建立全备RMAN备份记录和物理文件不一致控制文件元数据异常catalog start with重新扫描备份目录重建元数据fio测试导致多路径链路切换压测打到裸设备或非标准路径检查multipath -ll状态恢复路径配置避免在生产盘上压测信创系统fio安装异常系统源无fio包或内核不兼容使用系统包管理器安装或找到匹配的rpm包避免在生产节点随意编译主库归档目录写满归档传备库失败归档堆积清理归档修复备库链路调整归档策略这里面还想特别强调一个容易被忽略的小技巧。遇到备库gap过大的时候很多人第一反应是用以下命令手动注册缺失的日志alter database register or replace logfile /arch/orcl_1_100_123456.arc;这种做法在小gap场景下没问题但如果gap比较大或者归档文件本身已经被破坏就不要再做无谓的补救了直接重建备库才是性价比最高的选择。花一个小时重建一个备库比花半天时间去手工补一堆有问题的归档要省心得多而且数据一致性更有保障。6. 写在最后的一点真实体会我个人在实际操作中的体会是信创项目里数据库本身出故障的概率其实远低于“外部因素把数据库搞挂”的概率。机器重启、多路径切换、存储性能降低、文件系统异常随便一个都够让数据库喝一壶。fio这种工具本质就是个极度高效的IO压力发生器用对地方是性能测试利器用错地方就是事故制造机。如果你所在团队也正准备做信创性能验收或者存储压测我的建议很简单先把压测方案拿给DBA过一遍看看压测对象和数据库环境是否交叉。哪怕只是提前十分钟看一眼都能避免后面几个通宵的数据库恢复和容灾演练。真出了事也不要慌按止损、恢复主库、重建备库、修复备份的顺序一步步来前因后果理清楚之后问题都是能解决的。只是这种经历最好一辈子不要有第二次。

fio压测导致Oracle主备库与备份连环故障的复盘与恢复实战

相关推荐

humanizer技能：数据认知转译的四层实战方法论

.NET性能优化实战：从启动提速到异步编程的避坑指南

嵌入式洗碗机选购安装全攻略：大容量与智能烘干避坑指南

更多资讯

启动报Port 8088 was already in use？先查是谁占的

担心文档上云？本地运行的办公AI才敢放心用

先能用，再好用：从烂尾复盘到两周上线，全栈项目的‘原型—快速迭代‘方法论

深度思考模式把 ARC-AGI-2 从 17.6% 拉到 45.1%：对照 Gemini 3 Pro 的三份能力评测，看‘会思考‘改写了哪些边界

1.c++入门篇

《江灯合声》：有可行的分框版，也仍可以选择连续鸣谢

今日更新

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？