首页 » ORACLE 9i-23ai, 系统相关 » Troubleshooting XFS filesystem损坏恢复，与ASM start fail案例

Troubleshooting XFS filesystem损坏恢复，与ASM start fail案例

上个月那次“盆泼大瓢”式的暴雨差点导致一客户的服务器上船，但还是导致电源故障，在UPS支撑了一会儿中断，再次启动RAC中的一个节点，查看/u01 oracle 软件所在的文件系统无法查看， 重启后操作系统无法启动，后修复文件系统再次出现ASM无法启动问题，简单记录一下这个故障。

环境是Oracle 11.2.0.4 RAC on Linux 7, /u01使用的是xfs文件系统，还好根/文件系统正常， ls -l /u01无法读取，xfs格式文件系统损坏，经常发生在强制重启、异常关机、软件冲突、误删文件等事件后，系统盘容易出现文件系统损坏的情况，此时我们需要借助xfs_repair来进行修复。xfs_repair命令是xfs文件系统修复工具，需要先umount当前的文件系统.

dmesg日志

Aug 6 03:25:18 zdb002 kernel: XFS (sda3): Internal error XFS_WANT_CORRUPTED_RETURN at line 429 of file fs/xfs/libxfs/xfs_alloc.c. Caller xfs_alloc_ag_vextent_near+0x58d/0xa50 [xfs]
Aug 6 03:25:18 zdb002 kernel: CPU: 17 PID: 8011 Comm: kworker/u226:0 Kdump: loaded Tainted: P OE ------------ 3.10.0-1160.el7.x86_64 #1
Aug 6 03:25:18 zdb002 kernel: Hardware name: Inspur NF5280M5/YZMB-01360-102, BIOS 4.1.2 03/18/2022
Aug 6 03:25:18 zdb002 kernel: Workqueue: writeback bdi_writeback_workfn (flush-8:0)
Aug 6 03:25:18 zdb002 kernel: Call Trace:
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb7f81340>] dump_stack+0x19/0x1b
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc05b852b>] xfs_error_report+0x3b/0x40 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc05774bd>] ? xfs_alloc_ag_vextent_near+0x58d/0xa50 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc0574c04>] xfs_alloc_fixup_trees+0x2c4/0x370 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc05774bd>] xfs_alloc_ag_vextent_near+0x58d/0xa50 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc0577d2d>] xfs_alloc_ag_vextent+0x10d/0x150 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc057885b>] xfs_alloc_vextent+0x3eb/0x510 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc0586b08>] xfs_bmap_btalloc+0x7b8/0x7e0 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb79c1045>] ? mempool_alloc_slab+0x15/0x20
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc0586b3e>] xfs_bmap_alloc+0xe/0x10 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc0588497>] xfs_bmapi_write+0x4c7/0xb70 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc05d5df7>] ? kmem_zone_alloc+0x97/0x130 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc05c4d52>] xfs_iomap_write_allocate+0x182/0x380 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc05ae3c6>] xfs_map_blocks+0x1a6/0x220 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc05af404>] xfs_do_writepage+0x174/0x550 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb79c9d8c>] write_cache_pages+0x21c/0x470
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc05af290>] ? xfs_vm_writepages+0xa0/0xa0 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffc05af25b>] xfs_vm_writepages+0x6b/0xa0 [xfs]
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb79cade1>] do_writepages+0x21/0x50
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb7a7d6f0>] __writeback_single_inode+0x40/0x260
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb78c6cd5>] ? wake_up_bit+0x25/0x30
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb7a7e274>] writeback_sb_inodes+0x1c4/0x430
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb7a7e57f>] __writeback_inodes_wb+0x9f/0xd0
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb7a7ea53>] wb_writeback+0x263/0x2f0
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb7a6a67c>] ? get_nr_inodes+0x4c/0x70
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb7a7f64b>] bdi_writeback_workfn+0x2cb/0x460
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb78bdc4f>] process_one_work+0x17f/0x440
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb78bed66>] worker_thread+0x126/0x3c0
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb78bec40>] ? manage_workers.isra.26+0x2a0/0x2a0
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb78c5c21>] kthread+0xd1/0xe0
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb78c5b50>] ? insert_kthread_work+0x40/0x40
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb7f93df7>] ret_from_fork_nospec_begin+0x21/0x21
Aug 6 03:25:18 zdb002 kernel: [<ffffffffb78c5b50>] ? insert_kthread_work+0x40/0x40
Aug 6 03:25:18 zdb002 kernel: XFS (sda3): page discard on page fffff3e5e1027d40, inode 0x342efa33, offset 966656.
Aug 6 03:25:18 zdb002 kernel: XFS (sda3): writeback error on sector 514249960
0

XFS文件系统修复

lsblk 或df -Th查看文件系统挂载点与文件系统类型，如fsck修复EXT，而使用xfs_repair修复XFS.因为是非OS所在的文件系统/u01，启动到core模式尝试修复. 这个案例OS提示文件系统损坏，输入root密码后，自动进入OS，并且/u01也未mount，所以可以直接修复

如果无法启动OS,可以尝试如下方法：

进入GRUB界面，选择相应内核，按下‘e’键；通常第一行为内核，第二行为紧急救援模式；进入内核界面后，找到Linux16这行，末尾加上init=/bin/sh，‘Ctrl + x’ 进入单用户模式；（如果是/根文件系统损坏，需要进入救援模式，增加rw init=/sysroot/bin/sh）

先确保umount;执行xfs_repair -n xxx，检查文件系统是否损坏;执行xfs_repair修复文件系统; 如果报错使用xfs_repair -L xxx；

# xfs_repair -L /dev/sda3
# xfs_repair /dev/sda3

xfs_repair 实用程序无法修复带有脏日志的 XFS 文件系统。要清除日志，请挂载和卸载 XFS 文件系统。如果日志损坏且无法重播，请使用 -L 选项（”强制日志零”）清除日志，即 xfs_repair -L /dev/device。请注意，这可能导致进一步损坏或数据丢失.

修复完毕后执行reboot重启系统，问题解决。



ASM 无法启动问题


操作系统重启后，节点2DB实例未启动，检查ASM未启动。


crsctl stat res -t -init


检查所有资源正常online，但实际ASM实例未启动，


crsctl stat res -t


检查节点2ASM 和DB 未online。


ASM alert log日志显示


Warning: Oraping detected connectivity issues.
An eviction is expected due environment issues
OS ping to instance: 1 has failed.
Please see LMON and oraping trace files for details.





分析思路

节点间private netwrok 互相ping与traceroute测试

所有节点检查HAIP个数与网卡是否对应， 这个案有2个心跳网卡。

节点间HAIP互相ping 与traceroute测试

检查是否有firewall与iptables启动

检查private interconnect网卡的rp_filter是否是0或2

检查HAIP是否有route信息 netstat -rn


同事手快，怀疑是之前遇到的多haip的bug，ifdown 一个私网网卡，ASM启动正常，再次ifup 网卡，一切OK。


 


— over —


 

        

            打赏
            
        
	







, 








				





		
	
目前这篇文章有1条评论(Rss)评论关闭。

	

    
   
  1. 
     
    
      
    
                  cafe elektirikli soba | #1
        
     2023-09-07 at 00:57  
      
        
    
      
    
          
      	 
    
	 
    
      
    I am truly thankful to the owner of this web site who has shared this fantastic piece of writing at at this place.
    
      
    
      
    

     
       

    2. 





 








上一篇： 


下一篇：