2016-10-18 16 views
3

В случае сбоя сети или сбоя узла большинство распределенных атомных широковещательных протоколов (например, Расширенная виртуальная синхронизация или Paxos) требуют запускаемых узлов, чтобы вести протоколирование сообщений до тех пор, пока разбитый или разделенный узел не присоединится к кластеру. Когда узел присоединяется к кластеру, повторение записанных сообщений достаточно для восстановления текущего состояния.Сохраняет ли сообщения в службе групповой связи или практические действия paxos?

Мой вопрос в том, что если секционированный/аварийный узел занимает очень много времени, чтобы снова присоединиться к кластеру, то в конечном итоге журналы будут переполняться. Это, по-видимому, очень практичный вопрос, но никто в своей статье не говорит об этом. Есть ли очевидное решение для этого, которого я не вижу? Или мое понимание неверно.

+0

«... об этом никто в своей статье не говорит». Вы спрашиваете о конкретной бумаге? Или что никто никогда не пытается решить эту проблему? –

+0

Я прочитал статью, в основном связанную с услугами групповой связи, и там я не нашел, что это было поднято. Например, большинство виртуальных документов Synbcrony от Ken Birman, Extended Virtual Synchhony, CoREL и т. Д. –

ответ

2

Вам не нужно помнить весь журнал. Представьте себе, например, что состояние, которое вы синхронизировали между узлами, было чем-то вроде таблицы SQL с строкой формы (id: int, name: string), а команды, которые были записаны в журналы, были в форме «строка вставки» с id = x и name = y "," удалить строку, где id = z "," set name = a, где id = 1000 ", ...

Как только такие команды были совершены, все, что вам действительно интересно, это итоговый стол. Затем, как только узел, который был в автономном режиме в течение длительного времени, выходит в Интернет, ему нужно будет только загрузить таблицу + несколько записей из журнала, которые были зафиксированы во время загрузки таблицы.

Это называется «смятие журнала», см. Главу 7 в Raft paper для получения дополнительной информации.

2

Существует несколько потенциальных решений проблемы с бесконечным журналом, но одна из наиболее популярных для реплицированных конечных машин - это периодическое оснащение полного реплицированного конечного автомата и удаление всей истории до этой точки. Узел, который был слишком длинным в автономном режиме, просто отбросит всю свою информацию, загрузит снимок и начнет воспроизводить реплицированные журналы с этой точки.