Как заставить неактивное устройство RAID снова работать?

Для твоего бонусного вопроса:

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

Я обнаружил, что мне нужно добавить массив вручную в /etc/mdadm/mdadm.conf, чтобы заставить Linux смонтировать его при перезагрузке. В противном случае я получаю именно то, что у вас есть - md_d1-устройства, которые неактивны и т.д.

Conf-файл должен выглядеть так, как показано ниже - т.е. по одной строке ARRAY на каждое md-устройство. В моем случае новые массивы в этом файле отсутствовали, но если они есть в списке, то это, скорее всего, не является исправлением вашей проблемы.

# 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-устройство и добавьте их после комментария, включенного выше, или, если такого комментария нет, в конце файла. Вы получаете UUID, делая sudo mdadm -E --scan:

$ 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 рабочего стола 10.04 LTS, и насколько я помню, такое поведение отличается от серверной версии Ubuntu, однако это было так давно, что я создал свои md-устройства на сервере, что я могу ошибаться. Также может быть, что я просто пропустил некоторый вариант.

В любом случае, добавление массива в conf-файл, кажется, делает трюк. Я запустил указанный выше рейд 1 и рейд 5 в течение многих лет без проблем.

предупреждение: Прежде всего, позвольте мне сказать, что нижеприведенное (из-за использования “-силы”) кажется мне рискованным, и если у вас есть невосстановимые данные, я бы порекомендовал сделать копии соответствующих разделов, прежде чем вы начнете пробовать что-либо из нижеприведенного. Однако, это сработало для меня.

У меня была та же проблема, массив оказался неактивным, и ничто из того, что я делал, включая “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):

Тем не менее, подробности массива показали, что на нем были доступны 4 из 5 устройств:

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

(Вышеуказанное взято из памяти в колонке “Состояние”, я не могу найти его в буфере прокрутки).

я смог это разрешить, остановив массив, а затем снова собрав его:

[root@nfs1 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

В этот момент массив был запущен, работал с 4 из 5 устройств, и я смог добавить заменяющее устройство, и оно восстанавливается. Я смог получить доступ к файловой системе без каких-либо проблем.

У меня были проблемы с 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 пропустит любые системные сообщения, которые препятствуют вашей загрузке. В моем случае это было на удаленном сервере, поэтому это было необходимо.

Надеюсь, это поможет некоторым людям.

Вы можете активировать md-устройство с помощью

mdadm -A /dev/md_d0

Я полагаю, что какой-то скрипт запуска начнется слишком рано, до того, как один из членов RAID будет обнаружен или возникнет какая-то подобная проблема. В качестве быстрого и грязного обходного пути, вы должны быть в состоянии добавить эту строку в /etc/rc.local :

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

Правка : видимо ваш /etc/mdadm/mdadm.conf все еще содержит старое имя конфигурации. Отредактируйте этот файл и замените случайные совпадения md0 на md_d0.

У меня была похожая проблема… мой сервер не монтировал md2 после того, как я отрастил разделы устройств. Читая эту статью, я обнаружил, что устройство md2 RAID имеет новый и nbsp;UUID, а машина пыталась использовать старый.

Как и предполагалось… используя вывод ‘md2’ из

mdadm --examine --scan

я отредактировал /etc/mdadm/mdadm.conf и заменил старый UUID строку на один вывод из вышеприведенной команды, и моя проблема ушла в прошлое.

md_d0 : inactive sda4[0](S) выглядит неправильно для массива RAID1. Похоже, что в массиве нет активных устройств и есть одно запасное устройство (обозначается буквой (S), для неисправного устройства - буквой (F), для активного устройства - буквой (OK/active device) - для неработающего массива RAID1 должно быть как минимум два активных устройства (а для неисправного массива - как минимум одно активное устройство), и вы не можете активировать массив RAID1 без неработающих неработающих устройств (так как запасные устройства не содержат копии данных до тех пор, пока они не станут активными, когда другой диск не выйдет из строя). Если я считаю, что /proc/mdstat выводится правильно, то вы не сможете активировать массив в его текущем состоянии.

Есть ли у вас в машине физические диски, которые не раскрутились? ls /dev/sd* Перечисляет ли 0x6& все диски и разделы, которые вы обычно ожидаете увидеть на этой машине?

Когда вы притворяетесь, что что-то делаете с /dev/md[012346789} оно переходит на /dev/md{126,127...}./dev/md0 и продолжает монтироваться на /dev/md126 или /dev/md127, вы должны это сделать:

устанавливают /dev/md127 или устанавливают /dev/md126.

Это временно, чтобы позволить вам выполнять команды и некоторые приложения без остановки вашей системы.

Простой способ заставить массив работать в предположении отсутствия аппаратных проблем и наличия достаточного количества дисков/разделов для запуска массива заключается в следующем:

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

 sudo mdadm --manage /dev/md20 --run

Может быть, по какой-то причине массив в порядке, но что-то помешало ему запуститься или собраться. В моем случае это было из-за того, что mdadm не знал, что первоначальное имя массива - md127, и все диски были отключены для этого массива. При репликации мне пришлось собирать массив вручную (вероятно, это ошибка, при которой mdadm думал, что массив уже активен из-за старого автономного имени массива).