RAID-ресинсинг автоматически?

11

Я довольно случайно проверил состояние моих RAID-массивов cat/proc/mdstatи понял, что один из моих массивов, похоже, выполняет повторную синхронизацию:

md1 : active raid1 sdb7[1] sdc7[0]
      238340224 blocks [2/2] [UU]
      [==========>..........]  resync = 52.2% (124602368/238340224) finish=75.0min speed=25258K/sec

Почему это и что это значит? Я, похоже, могу получить доступ к точке монтирования просто с r/wразрешениями.

РЕДАКТИРОВАТЬ 1 (в ответ на ответ УУЗР )

Я ничего не вижу, если я grepпрошел, dmesgи --detailкоммутатор мне тоже ничего не говорит, то есть он показывает, что происходит повторная синхронизация ... но нет ни намека на причину или на то, почему она могла быть не синхронизирована ... - Думаю, мне просто нужно следить за этим, прежде чем я начну менять оборудование.

mdadm synchronization stdcerr
источник

Ответы:

10

Похоже, это указывает на то, что синхронизация между двумя членами RAID не синхронизирована друг с другом.

1. Исследуйте журналы

Я бы изучил ваши dmesgжурналы и посмотрел, есть ли сообщения о том, что какие-либо из физических жестких дисков, которые составляют этот массив, имеют аппаратные сбои.

2. Проверьте mdadm

Вы также можете проконсультироваться mdadmс помощью --detailпереключателя, чтобы узнать больше информации о повторной синхронизации следующим образом:

$ sudo mdadm --detail /dev/md0
/dev/md0:
        Version : 00.90.03
  Creation Time : Sat Jan 26 09:14:11 2008
     Raid Level : raid1
     Array Size : 976759936 (931.51 GiB 1000.20 GB)
  Used Dev Size : 976759936 (931.51 GiB 1000.20 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Fri Jan  1 01:29:16 2010
          State : clean, resyncing
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

 Rebuild Status : 50% complete

           UUID : 37a3bfcb:41393031:23c133e6:3b879f08
         Events : 0.2178969

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1

Если оба устройства выглядят нормально, и вы не можете точно определить, какое устройство имеет проблему, вы можете временно запустить диагностический инструмент, такой как HDAT2 или SpinRite, для каждого жесткого диска, чтобы подтвердить их работоспособность.

3. Кабели

Если проверить жесткие диски, я начну изучать кабели, обычно я их поменяю.

4. Контроллер

Затем я бы внимательно изучил сам контроллер, либо вынул диски из уязвимой системы и диагностировал их во вторичной системе, либо добавил плату контроллера стороннего производителя в уязвимую систему для дальнейшей диагностики проблемы.

5. Блок питания

Хотите верьте, хотите нет, но в прошлом у меня были проблемы с жесткими дисками и RAID-массивами, когда замена неисправного или почти неработающего источника питания решала мои проблемы со здоровьем RAID.

SLM
источник
@cerr - да, если повторная синхронизация будет происходить с случайными интервалами, то, скорее всего, один из жестких дисков находится на выходе, или 3,4, или 5. Проявление, которое вы описываете, у меня произошло Несколько раз я и это были те ситуации, которые разрешили эти неудачи, для меня, в прошлом.
СЛМ
8

Проверьте свои файлы cron, многие дистрибутивы выполняют запланированную повторную синхронизацию / повторную проверку раз в неделю.

В CentOS 7.1 он находится в /etc/cron.d/raid-check

# Run system wide raid-check once a week on Sunday at 1am by default
0 1 * * Sun root /usr/sbin/raid-check

Для настройки поведения отредактируйте / etc / sysconfig / raid-check

Sergio
источник
Хотя обычно это просто проверка, а не
повторная синхронизация
2
@frostschutz ... если только это не первое воскресенье месяца: serverfault.com/a/255549/299551 В этом случае повторная синхронизация принудительная.
Дан