Жил-был у меня gluster-mirror из двух машин. Жил он хорошо и клево, до тех пор пока я не начал делать бэкапы на этих двух машинах в gluster. Выбиралась машина, которая делает бэкапы, через flock прямо на гластере. И вот случился split-brain (машины потерялись связанность), бэкап сделался на обоих машинах, часть файлов получилась разной (потому что на одной из машин софт работать продолжал и писал новые файлы, а вторая машина вместо из-за отсутствия этих файлов пыталась записать другой diff бэкапа (с другим списком файлов)). А заодно и дампы баз разные получились, потому что вторая машина сделала пустой дамп с тем же именем.
В итоге при попытке сделать find по гластеру получаем кучу сообщений вида:
Ну и соответственно, невозможность работать с такими файлами. Тут стоит заметить, что «Input/output error» — это как раз о том, что файлы физически отличаются на двух нодах (кроме случаев, когда гластер вообще отвалился и IO error мы получаем на каждый файл).
В ходе попытки починить всё это родилась коротенькая команда, которая удаляет нам «неправильные» файлы и хардлинки на эти файлы с одной из машин (если не удалять хардлинки, то файлы восстановятся. При том неправильные).
Команду нужно запустить на той машине, которая по вашему мнению сгенерировала неправильные файлы. Обратите внимание, что /gluster в данном случае не точка монтирования гластера, а тот каталог, из которого вы создавали том гластера.
Сама команда (само собой, не забудьте заменить пути и проставить имя тома):
Что делать, если файлы попали в split-brain, но разные файлы в «правильной вариации» хранятся на разных машинах?
Придется чистить руками. Заодно и поймете, как работает моя команда выше.
Для начала получаем список «побившихся» файлов (тех, которые хранятся в разных экземплярах).
${volume-name} заменяем на имя своего тома (или выставляем переменную в шелле)
/backup/file
/backup/file2
...
Пути к файлам буду относительные. Соответственно, если у вас есть файл /backup/file в выводе команды, то в реальности он валяется в /gluster/backup/file в точке создания (не монтирования!) тома.
Дальше находим хардлинки на эти файлы, например:
/gluster/backup/file
/gluster/.glusterfs/a2/15/a2153490-8674-4b49-ad5b-ba5f23edd605
И удаляем сам файл и хардлинки на него:
После того, как мы удалили все неправильные копии файлов, лучше прогнать эдакий «ручной self-heal», чтобы всё проверить и посинкать информацию о файлах.
На одной из машин запускаем stat на все файлы в точке монтирования (!) гластера (то есть каталоге, куда смонтирован гластер-том). Если есть возможность (гластер не сильно нагружен в текущий момент) — то запускаем на всех машинах. Запускать команду лучше в скрине, она может работать достаточно долго (несколько суток на 14+ ТБ данных у меня, например):
Ну и в конце проверьте статус тома:
Удачи) Не болейте такой гадостью.
Полезно! И спасибо, помогли)
Та не за что