У нас есть старый Linux-сервер RAID 1 (Ubuntu Lucid 10.04) с четырьмя разделами. Несколько дней назад произошел сбой / dev / sdb, а сегодня мы заметили, что / dev / sda имел предаварийные зловещие признаки SMART (~ 4000 перераспределенных секторов). Сегодня утром мы заменили / dev / sdb и перестроили RAID на новом диске, следуя этому руководству:
http://www.howtoforge.com/replacing_hard_disks_in_a_raid1_array
Все шло гладко до самого конца. Когда казалось, что синхронизация последнего раздела завершается, другой старый раздел не удался. На данный момент я очень не уверен в состоянии системы. Все кажется работает, и все файлы кажутся доступными, как если бы он все синхронизировал, но я новичок в RAID и беспокоюсь о том, что происходит.
Вывод / proc / mdstat:
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md3 : active raid1 sdb4[2](S) sda4[0]
478713792 blocks [2/1] [U_]
md2 : active raid1 sdb3[1] sda3[2](F)
244140992 blocks [2/1] [_U]
md1 : active raid1 sdb2[1] sda2[2](F)
244140992 blocks [2/1] [_U]
md0 : active raid1 sdb1[1] sda1[2](F)
9764800 blocks [2/1] [_U]
unused devices: <none>
Получатель чего-то [_U] против [U_]. Почему они не согласованы по всему массиву? Первый U / dev / sda или / dev / sdb? (Я попытался найти в Интернете эту тривиальную информацию, но не нашел явных указаний) Если я правильно прочитал для md0, [_U] должно быть / dev / sda1 (вниз) и / dev / sdb1 (вверх). Но если / dev / sda не удалось, как это может быть напротив для мд3? Я понимаю, что / dev / sdb4 теперь резервный, потому что, вероятно, он не смог его синхронизировать на 100%, но почему он показывает / dev / sda4 как вверх? Не должно быть [__]? Или [_U] тем не мение? Диск / dev / sda теперь даже не может быть доступен SMART, поэтому я не ожидал, что он будет работать. Что не так с моей интерпретацией вывода?
Прилагаю также выходы mdadm --detail для четырех разделов:
/dev/md0:
Version : 00.90
Creation Time : Fri Jan 21 18:43:07 2011
Raid Level : raid1
Array Size : 9764800 (9.31 GiB 10.00 GB)
Used Dev Size : 9764800 (9.31 GiB 10.00 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Tue Nov 5 17:27:33 2013
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0
UUID : a3b4dbbd:859bf7f2:bde36644:fcef85e2
Events : 0.7704
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 17 1 active sync /dev/sdb1
2 8 1 - faulty spare /dev/sda1
/dev/md1:
Version : 00.90
Creation Time : Fri Jan 21 18:43:15 2011
Raid Level : raid1
Array Size : 244140992 (232.83 GiB 250.00 GB)
Used Dev Size : 244140992 (232.83 GiB 250.00 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Tue Nov 5 17:39:06 2013
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0
UUID : 8bcd5765:90dc93d5:cc70849c:224ced45
Events : 0.1508280
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 18 1 active sync /dev/sdb2
2 8 2 - faulty spare /dev/sda2
/dev/md2:
Version : 00.90
Creation Time : Fri Jan 21 18:43:19 2011
Raid Level : raid1
Array Size : 244140992 (232.83 GiB 250.00 GB)
Used Dev Size : 244140992 (232.83 GiB 250.00 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 2
Persistence : Superblock is persistent
Update Time : Tue Nov 5 17:46:44 2013
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 1
Spare Devices : 0
UUID : 2885668b:881cafed:b8275ae8:16bc7171
Events : 0.2289636
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 19 1 active sync /dev/sdb3
2 8 3 - faulty spare /dev/sda3
/dev/md3:
Version : 00.90
Creation Time : Fri Jan 21 18:43:22 2011
Raid Level : raid1
Array Size : 478713792 (456.54 GiB 490.20 GB)
Used Dev Size : 478713792 (456.54 GiB 490.20 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 3
Persistence : Superblock is persistent
Update Time : Tue Nov 5 17:19:20 2013
State : clean, degraded
Active Devices : 1
Working Devices : 2
Failed Devices : 0
Spare Devices : 1
Number Major Minor RaidDevice State
0 8 4 0 active sync /dev/sda4
1 0 0 1 removed
2 8 20 - spare /dev/sdb4
Активная синхронизация на / dev / sda4 сбивает меня с толку.
Я беспокоюсь, потому что, если завтра утром мне придется заменить / dev / sda, я хочу быть уверен, что мне следует синхронизировать с тем, что и что происходит. Меня также сбивает с толку тот факт, что / dev / sda решил потерпеть неудачу именно когда рейд закончил ресинхронизацию. Я хочу понять, что происходит на самом деле.
Большое спасибо за ваше терпение и помощь.
Массимо
Q1: Получатель чего-то [U] против [U]. Почему они не согласованы по всему массиву? Это первый U / dev / sda или / dev / sdb?
Порядок основан на номерах RaidDevice. Это числа в квадратных скобках таких строк:
md3 : active raid1 sdb4[2](S) sda4[0]
478713792 blocks [2/1] [U_]
md2 : active raid1 sdb3[1] sda3[2](F)
244140992 blocks [2/1] [_U]
md1 : active raid1 sdb2[1] sda2[2](F)
244140992 blocks [2/1] [_U]
...
Для md3 устройство sda4 - # 0. Устройство sdb4 - №2. Итак, U - это устройство sba4. Для md2 U - это устройство sda3, # 2. Таким образом, может показаться, что у вас есть проблемы с sdb, поскольку ни один из этих разделов не отображается как «UP», иначе говоря. «U». Все они обозначены как "ВНИЗ", иначе говоря. "_".
Q2: Разве это не должно быть [__]? Или [_U]?
Выход из /proc/mdstat должно быть все [UU]ака. они все "ВВЕРХ". Например, вот мой массив RAID1 с 2 участниками.
$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
976759936 blocks [2/2] [UU]
unused devices: <none>