Может ли откат по-прежнему происходить в реплике MongoDB с J=1 и W=Majority?
Я читал документы, и из своего понимания я видел сценарий, при котором откат все еще мог произойти:
- Запись идет на основной, который подтверждает, что журнал был записан на диск
- Большинство вторичных серверов подтверждают запись, но не записывают на диск
- Сбой питания на всем кластере
- Основной по какой-то причине не запускается обратно при восстановлении питания
- Второстепенный играет главную роль
- Первоначальный первичный, наконец, начинается, возвращается в набор как вторичный и откатывается
Этот сценарий правдоподобен?
3 ответа
Это может быть правдоподобным случаем для отката да, если происходит сбой питания между другими участниками, получающими команду и записывающими на диск.
В этом случае, как вы указали, первичный сервер не может начать резервное копирование и, таким образом, после резервного копирования будет содержать операции, которые остальная часть набора не может проверить, вызывая откат.
Также хорошо отметить, как кривая, что если бы основной не остановился, то он возвратил бы успешную запись, и приложение не было бы мудрее, что набор упал, и их {w: majority} не был записан на диск. Это, конечно, крайний случай.
Не думайте, что это произойдет в MongoDB 3.2+, как здесь, вы видите:
Изменено в версии 3.2: С помощью j: true MongoDB возвращается только после того, как запрошенное число членов, включая первичных, записало в журнал. Ранее для задания записи j: true в наборе реплик требовалось только первичное запись в журнал, независимо от задания w: write.
Исходя из документов, я понимаю, что если вы установите J =1, то W> 1 не имеет значения. Ваше приложение будет иметь запись ack'd только один раз (и как только) первичное лицо совершит запись в свой собственный журнал. произойдет запись в реплики, но не учитывайте ваши проблемы с записью.
в свете этого, сенарио "может первичный зафиксировать журнал, подтвердить запись и заставить кластер выключиться до того, как вторичные серверы зафиксируют свой журнал, а затем откатить первичный, когда вторичный сервер возвращается как первичный", является более скорее всего (но все еще с очень низкой вероятностью), чем предполагает первоначальный вопрос.
из документов:
Requiring journaled write concern in a replica set only requires a journal commit of the write
operation to the primary of the set regardless of the level of replica acknowledged write concern.