Как прервать ресинхронизацию программного RAID?

Я хочу прервать выполняющуюся операцию ресинхронизации на программном RAID в Debian Squeeze. (Это регулярная запланированная проверка ресинхронизации. Массив RAID остается чистым в таком случае. Не путайте это с перестройкой после сбоя и замены диска.)

Как остановить эту запланированную операцию ресинхронизации, пока она выполняется? Другой массив RAID “ожидает ресинхронизацию”, потому что все они проверяются в один и тот же день (в воскресенье ночью) один за другим. Я хочу полностью остановить эту воскресную ночную ресинхронизацию.

[Редактировать: sudo kill -9 1010 не останавливает ее, 1010 – это PID процесса md2_resync]

Я также хотел бы узнать, как я могу контролировать интервалы между ресинхронизациями и оставшееся время до следующей.

[Редактировать2: Что я сделал сейчас – это замедлил процесс ресинхронизации, чтобы он больше не мешал:

sudo sysctl -w dev.raid.speed_limit_max=1000

взято с http://www.cyberciti.biz/tips/linux-raid-increase-resync-rebuild-speed.html

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

Этот обходной путь приемлем для большинства ситуаций, тем не менее, было бы интересно узнать, возможно ли то, что я спрашивал. Например, кажется, что нельзя увеличить массив, пока он ресинхронизируется или “ожидает ресинхронизацию”]

Если ваш массив называется md0, то echo "idle" > /sys/block/md0/md/sync_action

‘idle’ остановит активную
ресинхронизацию/восстановление и т.п. Однако нет
гарантии, что другая ресинхронизация/восстановление
не начнется автоматически снова, хотя для этого потребуется
какое-то событие.

http://www.mjmwired.net/kernel/Documentation/md.txt#477

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

На моем Debian Lenny :

• echo "idle" > /sys/block/md0/md/sync_action работает, но процесс ресинхронизации тут же перезапускается.

• checkarray -x --all : работает, но тот же результат: процесс ресинхронизации тут же перезапускается.

Так что я использую этот метод:
echo 0 > /proc/sys/dev/raid/speed_limit_max

Вы можете отменить текущую ресинхронизацию массива, используя следующую последовательность команд (от root):

echo frozen > /sys/block/md0/md/sync_action
echo none > /sys/block/md0/md/resync_start
echo idle > /sys/block/md0/md/sync_action

Обратите внимание, что это может оставить ваш массив в несогласованном состоянии. Не делайте этого, если вы не уверены, что массив в хорошем состоянии, и повторите синхронизацию позже.

(Признание там, где оно заслужено: нашел эту инкапсуляцию в этом потоке.)

Как уже упоминалось выше, на системах Debian/Ubuntu скрипт /etc/cron.d/mdadm вызывает скрипт /usr/share/mdadm/checkarray для запуска проверок ресинхронизации.

В этом скрипте есть опция для отмены всех запущенных проверок синхронизации:

/usr/share/mdadm/checkarray -x --all

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

Моя система: CentOS 6.5
mdadm v3.3.2

Постоянные проверки каждую неделю, хотел приостановить одну из них, RAID чистый, проверка была вызвана через скрипт /etc/cron.d/raid-check, который запускается еженедельно.

Чтобы отменить проверку, используйте функцию –misc –action. Предположим, устройство RAID – /dev/md0, и это просто еженедельная проверка консистентности, а не сбой устройства, тогда вы, от root:

mdadm –misc –action=idle /dev/md0

Аналогично, для начала проверки консистентности

mdadm –misc –action=check /dev/md0

Не уверен, как отменить ресинхронизацию, но расписание контролируется файлом /etc/cron.d/mdadm на системах Debian/Ubuntu.

Скрипт /usr/share/mdadm/checkarray может пролить свет на другую часть вашего вопроса, так как он вызывается cron.

Если ваше устройство md – это md0 и вы хотите остановить ресинхронизацию, напишите:

echo "idle" > /sys/block/md0/md/sync_action

echo "idle" > /sys/block/md0/md/sync_action

Не работает, когда /sys/block/md*/md/sync_action равно “resync” (в отличие от состояния “check” или “repair”). Вы можете отправить “idle” в файл sync_action, но это не влияет на прогресс. Этот файл документации ядра здесь неправильно утверждает, что это будет работать, но у меня это никогда не работало:

‘idle’ остановит активную ресинхронизацию/восстановление и т.п. Тем не менее, нет гарантии,
что другая ресинхронизация/восстановление не сможет начаться автоматически снова,
хотя для этого потребуется какое-то событие.

Я попробовал ответ от “@bill.rookard”: “mdadm --misc --action=idle /dev/md0“, чтобы остановить текущий процесс восстановления, НО процесс восстановления не остановился (или возможно остановился и сразу же перезапустился).

Затем я проверил страницу руководства “mdadm”:

–action=… : Устанавливает “sync_action” для всех указанных md устройств на idle, frozen, check, repair. Установка в idle прервет любую текущую операцию, хотя некоторые действия могут автоматически перезапуститься. Установка в frozen прервет любую текущую операцию и гарантирует, что никакая другая операция не запустится автоматически.

И, наконец, выполнение: “mdadm --misc --action=frozen /dev/md0” остановило восстановление. Я смог перезагрузиться и выполнить обслуживание сервера. И после возврата в онлайн: “mdadm --misc --action=check /dev/md0” продолжило процесс восстановления с того места, где он был прекращен. Все в порядке.

Я знаю, что это сообщение было опубликовано 4 года назад, но вы также можете сделать следующее (предполагая, что md0 – массив, а sdb4 – “диск”, находящийся в процессе ресинхронизации):

    mdadm /dev/md0 --fail /dev/sdb4 && mdadm /dev/md0 --remove /dev/sdb4

Эта команда притворяется, что sdb4 – это сбойный диск, и поэтому исключает его из массива, останавливая ресинхронизацию. Если при остановке ресинхронизации ошибок не произошло, эта команда также удалит sdb4 из массива md0. Если произошла какая-либо ошибка, то диск остается в состоянии сбоя, но остается в массиве.

Если вы допускаете сбой на диске в любом месте в mdadm, вы устанавливаете его логически в состояние сбоя. Если массив был чистым (не в деградированном состоянии), то диск остается согласованным и может быть повторно добавлен с помощью опции –add << disk >> –assume-clean без страха. Если после его отключения было предпринято любое действие (например, ресинхронизация, перестройка или даже запись), то –assume-clean, вероятно, даст сбой и сразу же начнется действие ресинхронизации.

Изменение raid.speed_limit_min и raid.speed_limit_max – это в некотором роде плохая идея, потому что это влияет не только на скорости ресинхронизации/перестройки, но и на скорости обычных операций, и, вероятно, вы потеряете много производительности, полученной с помощью RAID массивов.