Является ли ведение журнала сообщений в службе групповой связи или paxos практичным?

#distributed-computing #distributed #paxos

#распределенные вычисления #распределенный #paxos

Вопрос:

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

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

Комментарии:

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

2. Я прочитал статью, в основном связанную с службами групповой связи, и там я не обнаружил, что это было поднято. Например, большинство статей Кена Бирмана о виртуальной синхронизации, расширенной виртуальной синхронизации, CoREL и т. Д.

Ответ №1:

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

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

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

Ответ №2:

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