it-swarm-ja.com

非アクティブなRAIDデバイスを再度機能させる方法は?

起動後、私のRAID1デバイス(/dev/md_d0 *)が時々おかしい状態になり、マウントできません。

*もともと私は/dev/md0を作成しましたが、それはどういうわけかそれ自身を/dev/md_d0に変えました。

# mount /opt
mount: wrong fs type, bad option, bad superblock on /dev/md_d0,
       missing codepage or helper program, or other error
       (could this be the IDE device where you in fact use
       ide-scsi so that sr0 or sda or so is needed?)
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

RAIDデバイスはどういうわけか非アクティブに見えます。

# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] 
                [raid4] [raid10] 
md_d0 : inactive sda4[0](S)
      241095104 blocks

# mdadm --detail /dev/md_d0
mdadm: md device /dev/md_d0 does not appear to be active.

問題は、デバイスを再度アクティブにする方法mdmadmを使用していると思います)です。

(それ以外の場合は起動後に問題なく(アクティブに)起動でき、手動で問題なくマウントできますが、/etc/fstabに格納していても自動的にはマウントされません。

/dev/md_d0        /opt           ext4    defaults        0       0

ボーナス質問:起動時にRAIDデバイスを/optに自動的にマウントさせるにはどうすればいいですか?

これはUbuntu 9.10ワークステーションです。 この質問の私のRAID設定に関する背景情報

編集:私の/etc/mdadm/mdadm.confはこんな感じです。私はこのファイルには少なくとも手で触れたことがない。

# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR <my mail address>

# definitions of existing MD arrays

# This file was auto-generated on Wed, 27 Jan 2010 17:14:36 +0200

/proc/partitionsでは、少なくとも現在、再起動後、デバイスが再びアクティブになったときの最後のエントリはmd_d0です。 (アクティブでなくても同じかどうかはわかりません)。

解像度Jimmy Hedmanが示唆したようにmdadm --examine --scanの出力を取りました。

ARRAY /dev/md0 level=raid1 num-devices=2 UUID=de8fbd92[...]

そしてそれを/etc/mdadm/mdadm.confに追加しました。これは主な問題を修正したようです。 /etc/fstabを(/dev/md0の代わりに)再び/dev/md_d0を使用するように変更した後、RAIDデバイスも自動的にマウントされます!

29
Jonik

あなたのボーナス質問のために:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf
24
Jimmy Hedman

Linuxが再起動時にそれをマウントするようにするために、/etc/mdadm/mdadm.confに手動でアレイを追加しなければならないことがわかりました。さもなければ私は丁度あなたがここに持っているものを手に入れる - md_d1-非アクティブな装置など.

Confファイルは以下のようになります - すなわち、各mdデバイスに対して1つのARRAY-行です。私の場合、このファイルに新しい配列がありませんでしたが、それらをリストしている場合、これはおそらく問題を解決するものではありません。

# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

Mdデバイスごとに1つの配列を追加し、上記のコメントの後、またはそのようなコメントが存在しない場合はファイルの末尾にそれらを追加します。 Sudo mdadm -E --scanを実行してUUIDを取得します。

$ Sudo mdadm -E --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d

ご覧のとおり、スキャン結果の出力をファイルにコピーするだけで十分です。

私はubuntu desktop 10.04 LTSを実行していますが、この動作がサーババージョンのUbuntuと異なることを私が覚えている限りでは、それは私が間違っているのかもしれません。私はいくつかの選択肢を逃したということかもしれません。

とにかく、confファイルに配列を追加することはトリックをするようです。私は何年もの間、上記のraid 1とraid 5を何の問題もなく実行しました。

10
Erik

警告:まず最初に、( "--force"を使用しているために)以下が危険であるように思われると言わせてください。回復不可能なデータ以下のことを試す前に、関係するパーティションのコピーを作成することをお勧めします。しかし、これは私のために働いた。

私は同じ問題を抱えていて、配列が非アクティブとして表示されていましたが、他の人が示唆しているように "mdadm --examine --scan> /etc/mdadm.conf"を含めて何もしませんでした。

私の場合、ドライブを交換した後にRAID 5アレイを起動しようとすると、(dmesg経由で)汚れていると言っていました。

md/raid:md2: not clean -- starting background reconstruction
md/raid:md2: device sda4 operational as raid disk 0
md/raid:md2: device sdd4 operational as raid disk 3
md/raid:md2: device sdc4 operational as raid disk 2
md/raid:md2: device sde4 operational as raid disk 4
md/raid:md2: allocated 5334kB
md/raid:md2: cannot start dirty degraded array.

/proc/mdstatで非アクティブとして表示されるようにします。

md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5]
      3888504544 blocks super 1.2

交換したドライブ(/dev/sdb4)を除いて、すべてのデバイスで同じイベントが発生していることがわかりました。

[[email protected] sr]# mdadm -E /dev/sd*4 | grep Event
mdadm: No md superblock detected on /dev/sdb4.
         Events : 8448
         Events : 8448
         Events : 8448
         Events : 8448

しかし、アレイの詳細から、5つのデバイスのうち4つが利用可能であることがわかりました。

[[email protected] sr]# mdadm --detail /dev/md2
/dev/md2:
[...]
   Raid Devices : 5
  Total Devices : 4
[...]
 Active Devices : 4
Working Devices : 4
[...]
    Number   Major   Minor   RaidDevice State
       0       8        4        0      inactive dirty  /dev/sda4
       2       8       36        2      inactive dirty  /dev/sdc4
       3       8       52        3      inactive dirty  /dev/sdd4
       5       8       68        4      inactive dirty  /dev/sde4

(上記は "State"列のメモリからのものです。スクロールバックバッファには見つかりません)。

これを解決するには、アレイを停止してから再度組み立てます。

mdadm --stop /dev/md2
mdadm -A --force /dev/md2 /dev/sd[acde]4

その時点でアレイは起動し、5つのデバイスのうち4つで動作していましたが、交換用のデバイスを追加することができました。問題なくファイルシステムにアクセスできます。

7

Ubuntu 10.04でFStabのエラーが原因でサーバーが起動しないという問題がありました。

私は上記の解決策で述べたようにこのコマンドを実行しました:

mdadm --examine --scan >> /etc/mdadm/mdadm.conf

これにより、 "mdadm --examine --scan"の結果が "/etc/mdadm/mdadm.conf"に追加されます。

私の場合、これは次のとおりです。

ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0

これは偽の0です。自動的にマウントするための/ etc/fstabの私のコマンドは次のとおりです。

/dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0

ここで重要なことはあなたが "nobootwait"と "nofail"を持っているということです。 Nobootwaitは起動を妨げているシステムメッセージをスキップします。私の場合、これはリモートサーバー上にあったので不可欠でした。

これが何人かの人々に役立つことを願っています。

4
Nick Woodhams

/dev/md[012346789}で何かをするふりをすると、/dev/md{126,127...}に行きます。 /dev/md0/dev/md126または/dev/md127にマウントされたままです。

umount /dev/md127またはumount /dev/md126

これは、システムを停止させずにコマンドやいくつかのアプリケーションを実行させるための一時的なものです。

2
Vanderj68

あなたのmdデバイスを有効にすることができます

mdadm -A /dev/md_d0

RAIDメンバーの1人が発見される前、またはそれに似たような問題が発生する前に、起動スクリプトがすぐに起動すると思います。迅速で汚い回避策として、/ etc/rc.localにこの行を追加することができるはずです。

mdadm -A /dev/md_d0 && mount /dev/md_d0

編集:明らかにあなたの/etc/mdadm/mdadm.confはまだ古い設定名を含んでいます。このファイルを編集して、md0の発生箇所をmd_d0に置き換えます。

2
wazoox

私は同様の問題を抱えていた...私は関連するデバイスのパーティションを大きくした後私のサーバーはmd2をマウントしないでしょう。このスレッドを読むと、md2 RAIDデバイスに新しいUUIDがあり、マシンは古いUUIDを使おうとしていることがわかりました。

お勧めしますように...からの 'md2'出力を使用

mdadm --examine --scan

/etc/mdadm/mdadm.confを編集して、古いUUIDの行を上記のコマンドの出力に置き換えたところ、問題は解決しました。

2
Peter Errity

md_d0 : inactive sda4[0](S)はRAID1アレイでは正しくありません。アレイにアクティブなデバイスがなく、スペアデバイスが1つあることをお勧めします。 ((S)で示されているように、障害のあるデバイスの場合は(F)が表示され、OK /アクティブデバイスの場合は表示されません) - 性能が低下していないRAID1アレイの場合、少なくとも2つのOK /アクティブデバイスがあるはずです。 (性能が低下したアレイの場合は、少なくとも1台のOK /アクティブデバイス) そして、他のドライブが故障したときにアクティブになるまでスペアにデータのコピーが含まれていないため、故障していないスペアではないデバイスがないRAID1アレイをアクティブにすることはできません。その/proc/mdstatの出力を正しく読んでいるのであれば、現在の状態で配列をアクティブにすることはできません。

マシンにスピンアップに失敗した物理ドライブがありますか。 ls /dev/sd*はあなたがそのマシンで通常見ることになるだろうすべてのドライブとパーティションをリストしていますか?

1
David Spillett

ハードウェアに問題がなく、アレイを起動するのに十分なドライブ/パーティションがあると仮定してアレイを動作させる簡単な方法は次のとおりです。

md20 : inactive sdf1[2](S)
      732442488 blocks super 1.2

 Sudo mdadm --manage /dev/md20  --run

それは、何らかの理由で配列が正常であるにもかかわらず、何かが原因で配列の起動や構築が妨げられた可能性があります。私の場合、これはmdadmが元のアレイ名がmd127であることを知らず、そのアレイのすべてのドライブが取り外されたためです。再プラグインするとき、私は手動でアセンブルしなければなりませんでした(おそらく、mdadmがオフラインの古いアレイ名のためにすでにアレイがアクティブであると思ったバグです)。

1
Areeb Soo Yasir