Вопросы Теги

Spring Boot Mongodb Replica Set работает не так, как ожидалось [дубликат]

В Java все переменные, которые вы объявляете, на самом деле являются «ссылками» на объекты (или примитивы), а не самими объектами.

При попытке выполнить один метод объекта , ссылка просит живой объект выполнить этот метод. Но если ссылка ссылается на NULL (ничего, нуль, void, nada), то нет способа, которым метод будет выполнен. Тогда runtime сообщит вам об этом, выбросив исключение NullPointerException.

Ваша ссылка «указывает» на нуль, таким образом, «Null -> Pointer».

Объект живет в памяти виртуальной машины пространство и единственный способ доступа к нему - использовать ссылки this. Возьмем этот пример: 

public class Some {
    private int id;
    public int getId(){
        return this.id;
    }
    public setId( int newId ) {
        this.id = newId;
    }
}

И в другом месте вашего кода: 

Some reference = new Some();    // Point to a new object of type Some()
Some otherReference = null;     // Initiallly this points to NULL

reference.setId( 1 );           // Execute setId method, now private var id is 1

System.out.println( reference.getId() ); // Prints 1 to the console

otherReference = reference      // Now they both point to the only object.

reference = null;               // "reference" now point to null.

// But "otherReference" still point to the "real" object so this print 1 too...
System.out.println( otherReference.getId() );

// Guess what will happen
System.out.println( reference.getId() ); // :S Throws NullPointerException because "reference" is pointing to NULL remember...

Это важно знать - когда больше нет ссылок на объект (в пример выше, когда reference и otherReference оба указывают на null), тогда объект «недоступен». Мы не можем работать с ним, поэтому этот объект готов к сбору мусора, и в какой-то момент VM освободит память, используемую этим объектом, и выделит другую.

2
задан Paul Verest 26 November 2013 в 05:31
поделиться

4 ответа

Ожидается, что, поскольку большинство членов отключены, MongoDB не предполагает, что последний оставшийся член согласован.

Когда у вас есть большинство участников, есть несколько вариантов: http://docs.mongodb.org/manual/tutorial/reconfigure-replica-set-with-unavailable-members/

8
ответ дан Sammaye 19 August 2018 в 10:23
поделиться
  • 1
    Воображаемая и смоделированная ситуация заключается в том, что остается только PRIMARY (например, другие недоступны для сетевой проблемы). PRIMARY - единственный экземпляр mongod, который принимает записи, поэтому он всегда имеет самые последние данные. Результатом текущей реализации MongoDB является то, что в течение 5-10 секунд ReplicaSet захватывает работу. – Paul Verest 18 November 2013 в 03:57
  • 2
    @PaulVerest, когда осталось только первичное из набора реплик из 3 членов, большинство из них не работает ... Я не следую вашей проблеме – Sammaye 18 November 2013 в 10:34
  • 3
    Для выборов необходимо большинство. Я не вижу веских оснований для того, чтобы PRIMARY сдался и захватил, чтобы принять записи. По крайней мере, не было видно ни одной документации, которая говорит об этом. – Paul Verest 18 November 2013 в 11:53
  • 4
    @PaulVerest - есть веская причина, почему PRIMARY отказался от ОСНОВНОГО ... Поскольку он не может видеть большинство, он не знает, все ли они все еще, могут видеть друг друга и выбрать новую ОСНОВНУЮ - Следовательно, проблема сетевого раздела, упомянутая Sammaye – Alan Spencer 19 November 2013 в 20:07
  • 5
    @PaulVerest см. Мой ответ - большинство необходимо для выборов, но большинство также необходимо для первичного, чтобы оставаться первичным. То есть если узел не может быть избран, он не может оставаться первичным. – Asya Kamsky 24 November 2013 в 02:48

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

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

С точки зрения двух второстепенных, сетевой раздел такой же, как первичный, недоступен, и с точки зрения первичной сети сетевой раздел неотличим от «обоих остальных узлов». Он уходит в отставку, потому что в случае сетевого раздела уже может быть другой первичный с другой стороны, и он уверяет, что не может быть двух праймериз, спустившись вниз.

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

Я высоко рекомендуйте отличную серию «назовите меня, возможно», чтобы прочитать проблемы доступности записи в распределенной системе: http://aphyr.com/posts/281-call-me-maybe-carly-rae-jepsen- и самая опасность-оф-сеть-разбиения

5
ответ дан Asya Kamsky 19 August 2018 в 10:23
поделиться
  • 1
    Прости меня, если я ошибаюсь, но он не имеет дело с сетевым разделом. Также не ответит тур о согласованности? – Sammaye 24 November 2013 в 03:54
  • 2
    Как какой-нибудь узел в реплике отличает сетевой раздел от сценария OP? – Asya Kamsky 24 November 2013 в 11:26
  • 3
    Я думал, что не помню, чтобы прочитать, что MongoDB имеет внутренний метод знания, когда есть раздел в конфигурации реплики? – Sammaye 24 November 2013 в 12:51
  • 4
    Я хочу сказать, что НЕВОЗМОЖНО различать сетевой раздел и остальные узлы. Нет никакой разницы с точки зрения каждого узла! – Asya Kamsky 24 November 2013 в 21:20
  • 5
    О, хорошо, просто кажется, что через простые знания IP / местоположения, используя конфигурацию реплики, это может быть очень легко понять, и я просто помню, как читал где-то, что MongoDB сделал, но если это не все нормально – Sammaye 24 November 2013 в 23:04

Просто чтобы услышать ответы. Ожидается поведение в этом сценарии. MongoDB использует алгоритм выбора лидера для избрания нового лидера. Так что, если нет большинства, вы не можете выбрать лидера и, следовательно, не писать.

Ваш единственный вариант в точке, где два узла опущены, состоит в том, чтобы перенастроить ваш набор реплик как набор реплик 1 узла, чтобы сделать его доступным для записи , Вы можете сделать это с помощью команды rs.reconfig cmd только с одним сервером. Однако учтите, что это должна быть временная и аварийная конфигурация. Для большей продолжительности вы должны иметь нечетное количество общих узлов (3+) в вашей конфигурации реплики.

1
ответ дан Dharshan 19 August 2018 в 10:23
поделиться

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

From http: // docs.mongodb.org/manual/core/replica-set-architectures/:

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

Подробнее о выборах: http://docs.mongodb.org/manual/core/replica -set-election /

Подробнее о судьях: http://docs.mongodb.org/manual/faq/replica-sets/#how-many-arbiters-do- реплики-наборы, необходимо

-1
ответ дан Marcos Zolnowski 19 August 2018 в 10:23
поделиться
  • 1
    Если большинство снизится, то есть 2/3, я сомневаюсь, что один или даже два arbs помогут много, это проблема более существенная, чем просто использование arbs – Sammaye 24 November 2013 в 23:02
  • 2
    На самом деле, чтобы добавить к этому, я бы подумал об этом плохом совете, так как настроить его набор реплик с тем, что вы предполагаете, ему понадобится значительное количество arbs (если бы он работал даже в своем сценарии, чего не будет, потому что в каждом сценарий, который он говорит о том, что у него есть большинство) и, таким образом, создание большого количества членов dud в наборе – Sammaye 24 November 2013 в 23:07
Другие вопросы по тегам:

Похожие вопросы: