Онлайн-восстановление mnesia из сетевого раздела

Ответ 1

После некоторых экспериментов я обнаружил следующее:

• Mnesia считала, что сеть должна быть разделена, если между двумя узлами есть разъединение node и повторное подключение без перезапуска mnesia.
• Это верно, даже если никакие операции чтения/записи Mnesia не происходят во время отключения.
• Mnesia сама должна быть перезапущена, чтобы очистить многораздельное сетевое событие - вы не можете force_load_table после разделения сети.
• Чтобы очистить сетевое разделенное событие, необходимо перезапустить только Mnesia. Вам не нужно перезапускать все node.
• Mnesia разрешает сетевое разделение, перезапуская Mnesia node, перезаписывая свои данные таблицы другими данными Mnesia node (алгоритм загрузки таблицы загрузки).
• Обычно узлы будут копировать таблицы из node, которые были самыми длинными (это было поведение, которое я видел, я не проверял, что это явно закодировано, а не побочный эффект чего-то другого). Если вы отсоедините node от кластера, сделайте запись в обоих разделах (отключенный node и его старые сверстники), выключите все узлы и снова запустите их, запустив сначала отключенный node, отключенный node будет считаться мастером, и его данные будут перезаписывать все остальные узлы. Нет поведения сравнения таблиц/контрольных сумм/кворума.

Итак, чтобы ответить на мой вопрос, можно выполнить полуавтоматическое восстановление, выполнив mnesia:stop(), mnesia:start() на узлах раздела, данные которых вы решите отказаться (что я буду называть проигрывающим разделом). Выполнение вызова mnesia:start() приведет к тому, что node будет обращаться к узлам с другой стороны раздела. Если в проигрывающем разделе имеется более одного node, вы можете захотеть установить основные узлы для загрузки таблицы в узлы в выигрышном разделе - в противном случае я думаю, что есть вероятность, что он загрузит таблицы из другого node в потерять раздел и, таким образом, вернуться в состояние секционированной сети.

К сожалению, mnesia не поддерживает поддержку слияния/согласования содержимого таблицы во время фазы загрузки загрузочной таблицы и не предусматривает возврата к фазе загрузки таблицы после запуска.

Фаза слияния была бы подходящей для ejabberd, в частности, поскольку node все равно будет иметь пользовательские подключения и, следовательно, знает, какие записи пользователя он сам/должен быть самым современным (при условии, что один пользователь подключается к кластеру), Если существует фаза слияния, node может фильтровать таблицы пользовательских данных, сохранять все записи для подключенных пользователей, загружать таблицы как обычно, а затем записывать сохраненные записи обратно в кластер mnesia.

Ответ 2

Это работает так. Представьте себе небо, полное птиц. Снимайте фотографии, пока не получите всех птиц. Поместите фотографии на стол. Сопоставляйте картинки друг над другом. Поэтому вы видите каждую птицу один раз. У вас есть каждая птица? ОК. Тогда вы знаете, в то время. Система была стабильной. Запишите, что звучат все птицы (сообщения), и сделайте несколько снимков. Затем повторите.

Если у вас есть node split. Вернитесь к последнему общему стабильному снимку. И попробуйте ** воспроизвести, что добавить после этого.:)

Это лучше описано в "Распределенные снимки: определение глобальных состояний распределенных систем" K. MANI CHANDY и LESLIE LAMPORT

** Я думаю, что есть проблема, решающая, какие часы следует выполнять при попытке воспроизвести то, что произошло

Ответ 3

Ответ Sara велик, даже посмотрите на статью о CAP. Разработчики Mnesia жертвуют P для CA. Если вам нужно P, то вам следует выбрать, что из CAP вы хотите принести в жертву и чем выбрать другое хранилище. Например CouchDB (жертва C) или Scalaris (жертва A).