Мы используем два сервера, разделенных глобальной сетью, для репликации примерно 1 ТБ данных.
На стороне мастера у нас есть один сервер с томом Gluster, экспортированным на ряд других серверов, которые записывают данные.
На стороне ведомого у нас есть один сервер с томом Gluster, экспортированным как общий ресурс только для чтения на серверы аварийного восстановления.
Со временем ведомое устройство стало рассинхронизировано с ведущим на уровне 200 ГБ, файлов, которые должны быть там, нет, а файлы, которые были удалены, остались. Похоже, что в этом нет большой последовательности.
Каков самый простой способ заставить кластер подсчитывать контрольную сумму каждого файла на ведомом устройстве и повторно реплицировать, где это необходимо?
В документации предлагается:
Описание: Гео-репликация GlusterFS не синхронизировала данные полностью, но статус георепликации все равно отображается нормально.
Решение: вы можете принудительно выполнить полную синхронизацию данных, удалив индекс и перезапустив георепликацию GlusterFS. После перезапуска GlusterFS Geo-replication начинает синхронизацию всех данных, то есть все файлы будут сравниваться с помощью контрольной суммы, что может быть длительной операцией с высокой степенью использования ресурсов, в основном для больших наборов данных (однако, фактическая потеря данных не произойдет). Если ошибка не исчезнет, обратитесь в службу поддержки 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 не работает. не предназначен для множественного изменения пула данных (распределенная ФС), а не для аварийного восстановления (резервное копирование только для чтения).
Короче говоря, георепликация - это модель ведущий / ведомый, где только главный сайт нажимает записи / изменения, и любые изменения периодически синхронизируются с удаленным только чтение раб.
Чтобы получить действительно распределенную реплицированную файловую систему, вам нужно было использовать функцию «Реплицированный том» GlusterFS. Недостатком является то, что при текущей схеме репликации записи должны быть синхронными: это означает, что при репликации между каналом WAN даже ваши локальные записи внутри локальной сети будут такими же медленными, как и путь WAN. Чтобы преодолеть этот предел, "Репликация нового стиля"рассматривается для включения, но, похоже, еще не реализован (по крайней мере, в стабильном корпоративном дистрибутиве).
Возвращаясь к вашей текущей ситуации, вы находитесь в классическом «сценарии разделения мозга», и я не уверен, что вы можете сделать: ваш главный и подчиненные устройства имеют разное представление о базовых томах и, вероятно, накопили разные несовместимые изменения в одном и том же файлы. Я думаю, вам пришлось (более или менее) вручную просмотреть их ...