test

Solaris ボリュームマネージャの管理

状態データベースの複製の障害からの回復

Procedure状態データベースの複製数の不足から回復するには

ドライブ障害などのために、状態データベースの複製の数が規定数に達していないと、システムをマルチユーザーモードで再起動できなくなります。 この状態になるのは、使用可能な状態データベースの複製の数が半数に達しないことを Solaris ボリュームマネージャが検出した後 (パニックの後) や、使用可能な状態データベースの複製の数が半数以下の状態でシステムが再起動されたときなどです。 Solaris ボリュームマネージャでは、これを、状態データベースの複製が「無効」状態になったといいます。 この問題から回復するための手順を次に示します。

手順

  1. システムを起動して、どの状態データベースの複製に障害があるのか調べます。

  2. 使用不能な状態データベースの複製を特定します。

    次の形式の metadb コマンドを実行します。 


    metadb -i

  3. 1 つまたは複数のディスクが使用不能であることがわかっている場合は、それらのディスク上の状態データベースの複製をすべて削除します。 そうでない場合は、障害のある状態データベースの複製 (metadb の出力のステータスフラグ W、M、D、F、R で示される) を削除して、状態データベースの複製の過半数が正常なものであるようにします。

    metadb -d コマンドを使って、不良ディスク上の状態データベースの複製を削除します。

    ヒント

    大文字の状態フラグが付いている状態データベースの複製は障害のある複製であり、小文字のフラグが付いているものは正常な複製です。

  4. metadb コマンドを使って、複製が削除されていることを確認します。

  5. システムを再起動します。

  6. 必要であれば、ディスクを交換し、適切にフォーマットしてから、必要な状態データベースの複製をディスクに追加します。 「状態データベースの複製の作成 」の指示に従います。

    交換用のディスクが用意できたら、システムを停止し、不良ディスクを交換してから、システムを再起動します。 format か fmthard コマンドを使って、障害の発生前と同じようにディスクをパーティション分割します。

例 261 状態データベースの複製数の不足から回復する

この例では、7 つの状態データベースの複製を含むディスクに障害が発生したものとします。 システムには正常な複製が 3 つしか残らないため、システムはパニック状態になり、マルチユーザーモードで再起動できなくなります。 


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 エラーメッセージが表示されますが、無視してください。

この時点でシステムは再び動作できるようになりますが、おそらく、システムには本来の数よりも少ない状態データベースの複製しかありません。また、障害が発生した記憶領域を使用していたボリュームは異常状態またはエラー状態になっているか、あるいはホットスペアで置き換えられています。このような問題は、速やかに解決しなければなりません。