Почему серверы конфигурации MongoDB должны быть только одним или тремя?
после прочтения официальной документации по архитектуре sharding MongoDB я не узнал, почему вам нужно иметь один или три сервера конфигурации, а не другой номер.
на документация MongoDB на серверах конфигурации говорит:
" Если один или два сервера конфигурации становятся недоступными, метаданные кластера становятся доступными только для чтения. Вы все еще можете читать и записывать данные из осколков, но никакие миграции или разбиения кусков не будут происходить до тех пор, пока все доступны три сервера."
следовательно, отражение: один сервер эквивалентен одной точке отказа, но с двумя серверами мы имеем то же поведение, что и три, верно?
Итак, почему абсолютно три сервера, а не только два или более, например?
потому что док также говорит:
серверы конфигурации не работают как наборы реплик.
1 ответов
Протоколы Сервера Конфигурации
MongoDB 3.0 и более ранние версии поддерживают только один тип протокола развертывания config server, который называется устаревшим SCCC (конфигурация подключения кластера синхронизации) с MongoDB 3.2. Развертывание СЦКК имеет 1 конфиг сервера (только развитие) или 3 сервера конфиг (производства).
MongoDB 3.2 устаревает протокол SCCC и поддерживает новый тип развертывания: серверы конфигурации как наборы реплик (CSRS). Развертывание CSRS имеет те же ограничения, что и стандартный набор реплик, который может иметь 1 сервер конфигурации (только разработка) или до 50 серверов (производство), как в MongoDB 3.2. Рекомендуется использовать не менее 3 серверов CSRS для обеспечения высокой доступности в производственном развертывании, но дополнительные серверы могут быть полезны для географически распределенных развертываний.
SCCC (конфигурация подключения кластера синхронизации)
С помощью SCCC серверы конфигурации обновляются с помощью двухфазной фиксации протокол что требует консенсуса от нескольких серверов для транзакции. Вы можете использовать один сервер конфигурации для тестирования/разработки, но в производственном использовании вы всегда должны иметь 3. Практический ответ на вопрос, почему вы не можете использовать только 2 (или более 3) сервера в MongoDB, заключается в том, что база кода MongoDB только поддерживает 1 или 3 сервера конфигурации для конфигурации SCCC.
3 сервера обеспечивают более сильную гарантию последовательности чем 2 сервера, и учитывают деятельность по обслуживанию (например, резервное копирование) на одном сервере конфигурации при наличии двух серверов, доступных для вашего mongos запрос. Более трех серверов увеличат время, необходимое для передачи данных по всем серверам.
метаданные для вашего sharded кластера должны быть идентичны на всех серверах конфигурации и поддерживаются реализацией sharding MongoDB. Метаданные включают в себя основные сведения о том, какие осколки в настоящее время содержат диапазоны документов (ака chunks). В конфигурации SCCC серверы конфигурации являются не набор реплик, поэтому, если один или несколько серверов конфигурации находятся в автономном режиме, то данные конфигурации будут считываться только -- в противном случае нет средств для распространения данных на автономные серверы конфигурации, когда они снова в сети.
четко 1 конфиг сервера не обеспечивает резервирование. С 2 серверами конфигурации сценарий потенциального сбоя - это когда серверы доступны, но данные на серверах не согласуются (например, один из серверов имел некоторое повреждение данных). С 3 серверами конфигурации вы можете улучшить предыдущий сценарий: 2/3 серверов могут быть согласованными, и вы можете определить нечетный сервер.
CSRS (серверы конфигурации как наборы реплик)
MongoDB 3.2 не одобряет использование трех зеркальных mongod экземпляры для серверов конфигурации и начиная с 3.2 серверы конфигурации (по умолчанию) развертываются как набор реплик. Серверы конфигурации набора реплик должны использовать WiredTiger 3.2+ механизм хранения (или другой механизм хранения, который поддерживает новый readConcern читать семантики изоляции). CSRS также запрещает некоторые параметры конфигурации набора реплик не по умолчанию (например,arbiterOnly, buildIndexes и slaveDelay), которые не подходят для случая использования метаданных sharded cluster.
развертывание CSRS улучшает согласованность и доступность для серверов конфигурации, так как MongoDB может воспользоваться стандартным набором реплик для чтения и записи протоколов для sharding config данные. Кроме того, это позволяет сегментированному кластеру иметь более 3 серверов конфигурации, так как набор реплик может иметь до 50 членов (как в MongoDB 3.2).
при развертывании CSRS доступность записи зависит от поддержания кворума членов, которые могут видеть текущий первичный для набора реплик. Например, 3-узел набор реплик потребует 2 членов для поддержания основного. Дополнительные элементы могут быть добавлены для улучшения отказоустойчивость, при этом правила проведения выборов как обычный набор реплик. А readConcern of majority используется mongos чтобы гарантировать, что метаданные кластера могут быть прочитаны только после того, как он зафиксирован для большинства членов набора реплик и readPreference of nearest используется для маршрутизации запросов на ближайший сервер конфигурации.