Debian.pro/

Про Debian


Лечим gluster после split-brain.

Жил-был у меня gluster-mirror из двух машин. Жил он хорошо и клево, до тех пор пока я не начал делать бэкапы на этих двух машинах в gluster. Выбиралась машина, которая делает бэкапы, через flock прямо на гластере. И вот случился split-brain (машины потерялись связанность), бэкап сделался на обоих машинах, часть файлов получилась разной (потому что на одной из машин софт работать продолжал и писал новые файлы, а вторая машина вместо из-за отсутствия этих файлов пыталась записать другой diff бэкапа (с другим списком файлов)). А заодно и дампы баз разные получились, потому что вторая машина сделала пустой дамп с тем же именем.

В итоге при попытке сделать find по гластеру получаем кучу сообщений вида:

find: `/gluster-mount/backup/mysqldumps/2014-05-14-19-15.sql.gz': Input/output error

Ну и соответственно, невозможность работать с такими файлами. Тут стоит заметить, что «Input/output error» — это как раз о том, что файлы физически отличаются на двух нодах (кроме случаев, когда гластер вообще отвалился и IO error мы получаем на каждый файл).
В ходе попытки починить всё это родилась коротенькая команда, которая удаляет нам «неправильные» файлы и хардлинки на эти файлы с одной из машин (если не удалять хардлинки, то файлы восстановятся. При том неправильные).

Команду нужно запустить на той машине, которая по вашему мнению сгенерировала неправильные файлы. Обратите внимание, что /gluster в данном случае не точка монтирования гластера, а тот каталог, из которого вы создавали том гластера.
Сама команда (само собой, не забудьте заменить пути и проставить имя тома):

root@server:~# for i in `gluster volume heal ${volume-name} info`; do find 2>/dev/null /gluster/ -samefile /gluster/$i -delete -print; done

Что делать, если файлы попали в split-brain, но разные файлы в «правильной вариации» хранятся на разных машинах?
Придется чистить руками. Заодно и поймете, как работает моя команда выше.
Для начала получаем список «побившихся» файлов (тех, которые хранятся в разных экземплярах).
${volume-name} заменяем на имя своего тома (или выставляем переменную в шелле)

root@server:~# gluster volume heal ${volume-name} info
/backup/file
/backup/file2
...

Пути к файлам буду относительные. Соответственно, если у вас есть файл /backup/file в выводе команды, то в реальности он валяется в /gluster/backup/file в точке создания (не монтирования!) тома.

Дальше находим хардлинки на эти файлы, например:

root@server:~# find /gluster/ -samefile /gluster/backup/file
/gluster/backup/file
/gluster/.glusterfs/a2/15/a2153490-8674-4b49-ad5b-ba5f23edd605

И удаляем сам файл и хардлинки на него:

root@server:~# rm -f /gluster/backup/file
root@server:~# rm -f /gluster/.glusterfs/a2/15/a2153490-8674-4b49-ad5b-ba5f23edd605

После того, как мы удалили все неправильные копии файлов, лучше прогнать эдакий «ручной self-heal», чтобы всё проверить и посинкать информацию о файлах.
На одной из машин запускаем stat на все файлы в точке монтирования (!) гластера (то есть каталоге, куда смонтирован гластер-том). Если есть возможность (гластер не сильно нагружен в текущий момент) — то запускаем на всех машинах. Запускать команду лучше в скрине, она может работать достаточно долго (несколько суток на 14+ ТБ данных у меня, например):

root@server:~# for i in `find /gluster/mount`; do stat 1>/dev/null $i; done

Ну и в конце проверьте статус тома:

root@server:~# gluster volume heal ${volume-name} info

Удачи) Не болейте такой гадостью.


Комментарии (2):

  1. Сергей :

    Полезно! И спасибо, помогли)

  2. Та не за что

Написать комментарий