跳过导航链接 | |
退出打印视图 | |
Solaris Volume Manager 管理指南 Oracle Solaris 10 1/13 Information Library (简体中文) |
4. Solaris Volume Manager for Sun Cluster(概述)
5. 配置和使用 Solaris Volume Manager(方案)
20. 维护 Solaris Volume Manager(任务)
21. Solaris Volume Manager 的最佳做法
25. Solaris Volume Manager 故障排除(任务)
Solaris Volume Manager 故障排除(任务列表)
Solaris Volume Manager 故障排除的一般原则
如何使用 Solaris Volume Manager 配置来恢复系统
A. 重要的 Solaris Volume Manager 文件
B. Solaris Volume Manager 快速参考
如果无法满足状态数据库副本定额(例如,由于驱动器故障),则系统无法重新引导至多用户模式。当 Solaris Volume Manager 发现可用的状态数据库副本不足一半时,可能会引发系统紧急情况。如果使用恰好一半或者更少的正常运行的状态数据库副本重新引导系统,也可能会出现这种情况。按 Solaris Volume Manager 术语来说,状态数据库已“过时”。以下过程说明如何从此问题中恢复。
# metadb -i
# metadb -d disk-slice
提示 - 带有大写状态标志的状态数据库副本是出错的副本。带有小写状态标志的状态数据库副本是正常运行的副本。
# metadb
# reboot
请按照创建状态数据库副本中的说明操作。
在拥有替换磁盘后,停止系统,替换故障磁盘,然后再次重新引导系统。使用 format 命令或 fmthard 命令按照磁盘出现故障之前的配置对磁盘进行分区。
示例 25-1 从过时的状态数据库副本中恢复
在以下示例中,包含七个副本的磁盘已出现错误。因此,系统只有三个良好的副本。系统将发生紧急情况,然后无法重新引导至多用户模式。
panic[cpu0]/thread=70a41e00: md: state database problem 403238a8 md:mddb_commitrec_wrapper+6c (2, 1, 70a66ca0, 40323964, 70a66ca0, 3c) %l0-7: 0000000a 00000000 00000001 70bbcce0 70bbcd04 70995400 00000002 00000000 40323908 md:alloc_entry+c4 (70b00844, 1, 9, 0, 403239e4, ff00) %l0-7: 70b796a4 00000001 00000000 705064cc 70a66ca0 00000002 00000024 00000000 40323968 md:md_setdevname+2d4 (7003b988, 6, 0, 63, 70a71618, 10) %l0-7: 70a71620 00000000 705064cc 70b00844 00000010 00000000 00000000 00000000 403239f8 md:setnm_ioctl+134 (7003b968, 100003, 64, 0, 0, ffbffc00) %l0-7: 7003b988 00000000 70a71618 00000000 00000000 000225f0 00000000 00000000 40323a58 md:md_base_ioctl+9b4 (157ffff, 5605, ffbffa3c, 100003, 40323ba8, ff1b5470) %l0-7: ff3f2208 ff3f2138 ff3f26a0 00000000 00000000 00000064 ff1396e9 00000000 40323ad0 md:md_admin_ioctl+24 (157ffff, 5605, ffbffa3c, 100003, 40323ba8, 0) %l0-7: 00005605 ffbffa3c 00100003 0157ffff 0aa64245 00000000 7efefeff 81010100 40323b48 md:mdioctl+e4 (157ffff, 5605, ffbffa3c, 100003, 7016db60, 40323c7c) %l0-7: 0157ffff 00005605 ffbffa3c 00100003 0003ffff 70995598 70995570 0147c800 40323bb0 genunix:ioctl+1dc (3, 5605, ffbffa3c, fffffff8, ffffffe0, ffbffa65) %l0-7: 0114c57c 70937428 ff3f26a0 00000000 00000001 ff3b10d4 0aa64245 00000000 panic: stopped at edd000d8: ta %icc,%g0 + 125 Type 'go' to resume ok boot -s Resetting ... Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 270MHz), No Keyboard OpenBoot 3.11, 128 MB memory installed, Serial #9841776. Ethernet address 8:0:20:96:2c:70, Host ID: 80962c70. Rebooting with command: boot -s Boot device: /pci@1f,0/pci@1,1/ide@3/disk@0,0:a File and args: -s SunOS Release 5.9 Version s81_39 64-bit Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved. configuring IPv4 interfaces: hme0. Hostname: dodo metainit: dodo: stale databases Insufficient metadevice database replicas located. Use metadb to delete databases which are broken. Ignore any "Read-only file system" error messages. Reboot the system when finished to reload the metadevice database. After reboot, repair any broken database replicas which were deleted. Type control-d to proceed with normal startup, (or give root password for system maintenance): root-password single-user privilege assigned to /dev/console. Entering System Maintenance Mode Jun 7 08:57:25 su: 'su root' succeeded for root on /dev/console Sun Microsystems Inc. SunOS 5.9 s81_39 May 2002 # metadb -i flags first blk block count a m p lu 16 8192 /dev/dsk/c0t0d0s7 a p l 8208 8192 /dev/dsk/c0t0d0s7 a p l 16400 8192 /dev/dsk/c0t0d0s7 M p 16 unknown /dev/dsk/c1t1d0s0 M p 8208 unknown /dev/dsk/c1t1d0s0 M p 16400 unknown /dev/dsk/c1t1d0s0 M p 24592 unknown /dev/dsk/c1t1d0s0 M p 32784 unknown /dev/dsk/c1t1d0s0 M p 40976 unknown /dev/dsk/c1t1d0s0 M p 49168 unknown /dev/dsk/c1t1d0s0 # metadb -d c1t1d0s0 # metadb flags first blk block count a m p lu 16 8192 /dev/dsk/c0t0d0s7 a p l 8208 8192 /dev/dsk/c0t0d0s7 a p l 16400 8192 /dev/dsk/c0t0d0s7 #
系统发生紧急情况,原因是它无法再检测到分片 /dev/dsk/c1t1d0s0 上的状态数据库副本。此分片位于故障磁盘上或者与故障控制器连接。第一个 metadb -i 命令将此分片上的副本标识为主块出现问题。
删除过时的状态数据库副本后,根 (/) 文件系统将成为只读系统。您可以忽略所显示的 mddb.cf 错误消息。
此时,尽管系统拥有的状态数据库副本可能不足,但仍然会重新正常运行。任何使用故障存储中某个部分的卷也将出现故障、出错或成为热备用卷。这些问题应该尽快解决。