Пересинхронизация Георепликации GlusterFS
Мы используем два сервера, разделенные WAN для тиражирования приблизительно 1 ТБ данных.
На основной стороне у нас есть единственный сервер с объемом Gluster, экспортируемым во многие другие серверы та запись в данных.
На ведомой стороне у нас есть единственный сервер с объемом Gluster, экспортируемым как доля только для чтения в серверы аварийного восстановления.
Со временем ведомое устройство становилось из синхронизации с ведущим устройством в размере 200 ГБ, файлы, которые должны быть, нет и файлы, которые были удалены. Кажется, нет большой непротиворечивости в этом.
Что самый простой путь состоит в том, чтобы вызвать кластер к контрольной сумме каждый файл на ведомом устройстве и повторно копировать при необходимости?
Документация предлагает:
Описание: Георепликация GlusterFS не синхронизировала данные полностью, но тем не менее дисплей геосостояния репликации хорошо.
Решение: можно осуществить полную синхронизацию данных путем стирания индекса и перезапуска Георепликации GlusterFS. После перезапуска Георепликация GlusterFS начинает синхронизировать все данные, то есть, все файлы будут по сравнению с посредством того, чтобы быть проверенным суммированием, который может быть длинным / ресурсом высокая операция использования, главным образом на больших наборах данных (однако, фактическая потеря данных не произойдет). Если ошибочная ситуация сохраняется, свяжитесь с Поддержкой Gluster.
Но не относится туда, где этот индекс может быть.
# gluster volume geo-replication share gluk1::share stop
Stopping geo-replication session between share & gluk1::share has been successful
# gluster volume set share geo-replication.indexing off
volume set: failed: geo-replication.indexing cannot be disabled while geo-replication sessions exist
Это индексное отключение перестало работать, в то время как соединение все еще существует вообще, и документация не упоминает это требование.
Какие-либо предложения?
Ваши ведомые вышли из синхронизации, потому что GlusterFS Geo-Replication - это , а не , предназначенная для многократного изменения пула данных (распределенного FS), а не для аварийного восстановления (резервное копирование только для чтения).
Короче говоря, георепликация - это мастер/ведомая модель, где только главный сайт нажимает на запись/изменения, и любые изменения периодически синхронизируются с удаленным ведомым только для чтения.
Чтобы иметь действительно распределенную, реплицированную файловую систему, вы должны были использовать функцию GlusterFS "Replicated Volume" ("Реплицированный том"). Недостатком является то, что при текущей схеме репликации записи вынуждены быть синхронными: это означает, что если вы реплицируете между WAN соединениями, то даже ваша локальная, внутри-LAN запись будет такой же медленной, как и WAN путь. Для преодоления этого ограничения рассматривается возможность включения "Репликация по новому стилю", но, похоже, она еще не реализована (по крайней мере, на стабильном, корпоративном дистрибутиве).
Возвращаясь к текущей ситуации, вы находитесь в классическом сценарии "split-brain", и я не уверен, что вы можете сделать: ваш хозяин и ведомые имеют разное представление о лежащих в основе томах, и они, вероятно, накопили разные, несовместимые изменения в одних и тех же файлах. Думаю, вам пришлось (более или менее) просматривать их вручную...
.