首页 » ORACLE 9i-23c, 系统相关 » 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.