Ответ 1
Конфигурирование протоколов сервера
MongoDB 3.0 и более ранние версии поддерживают только один тип протокола развертывания сервера конфигурации, который упоминается как устаревшая SCCC (конфигурация подключения кластера синхронизации) по сравнению с MongoDB 3.2. Развертывание SCCC имеет либо 1 конфигурационный сервер (только для разработки), либо 3 сервера конфигурации (производство).
MongoDB 3.2 обесценивает протокол SCCC и поддерживает новый тип развертывания: Config Servers as Replica Sets (CSRS). Развертывание CSRS имеет те же ограничения, что и стандартный набор реплик, который может иметь 1 конфигурационный сервер (только для разработки) или до 50 серверов (производство), как в MongoDB 3.2. Для обеспечения высокой доступности в производственном развертывании рекомендуется минимум 3 сервера CSRS, но дополнительные серверы могут быть полезны для географически распределенных развертываний.
SCCC (конфигурация подключения кластера синхронизации)
С помощью SCCC серверы конфигурации обновляются с использованием протокола двухфазного фиксации, который требует согласия нескольких серверов на транзакцию. Вы можете использовать один сервер конфигурации для целей тестирования/разработки, но при использовании продукции вы всегда должны иметь 3. Практический ответ, почему вы не можете использовать только 2 (или более 3) сервера в MongoDB, является то, что база кодов MongoDB только поддерживает 1 или 3 сервера конфигурации для конфигурации SCCC.
Три сервера обеспечивают более надежную гарантию согласованности, чем два сервера, и позволяют выполнять операции технического обслуживания (например, резервные копии) на одном сервере конфигурации, имея при этом еще два сервера для запроса mongos. Более трех серверов увеличили время, необходимое для фиксации данных на всех серверах.
Метаданные для вашего ошеломительного кластера должны быть одинаковыми для всех конфигурационных серверов и поддерживаться реализацией MongoDB sharding. Метаданные включают основные сведения о том, какие осколки в настоящее время содержат диапазоны документов (aka chunks). В конфигурации SCCC серверы конфигурации не являются наборами реплик, поэтому, если один или несколько серверов конфигурации находятся в автономном режиме, данные конфигурации будут считаны только для чтения - иначе нет средств для распространения данных на автономных серверах конфигурации, когда они назад в Интернете.
Очевидно, что 1 сервер конфигурации не обеспечивает резервирование или резервное копирование. С 2 конфигурационными серверами потенциальный сценарий сбоя - это то, где серверы доступны, но данные на серверах не согласуются (например, на одном из серверов было повреждение данных). С 3-мя конфигурационными серверами вы можете улучшить предыдущий сценарий: 2/3 сервера могут быть согласованными, и вы можете идентифицировать нечетный сервер.
CSRS (серверы конфигурации как наборы реплик)
MongoDB 3.2 отказывается от использования трех зеркальных экземпляров mongod для конфигурационных серверов, а начиная с 3.2 конфигурационных серверов (по умолчанию) развертывается как набор реплик. В конфигурационных серверах Replica необходимо использовать механизм хранения WiredTiger 3.2+ (или другой механизм хранения, который поддерживает новую readConcern прочитанную семантику изоляции). CSRS также запрещает некоторые параметры конфигурации набора не по умолчанию (например, arbiterOnly, buildIndexes и slaveDelay), которые непригодны для использования в случае использования метаданных с осколками кластера.
Развертывание CSRS повышает согласованность и доступность для серверов конфигурации, поскольку MongoDB может воспользоваться стандартными наборами для чтения и записи набора реплик для данных конфигурации sharding. Кроме того, это позволяет кластерному кластеру иметь более 3 конфигурационных серверов, поскольку набор реплик может содержать до 50 членов (как в MongoDB 3.2).
При развертывании CSRS доступность записи зависит от сохранения кворума членов, который может видеть текущий основной набор реплик. Например, набор реплик 3 node потребует наличия двух доступных элементов для поддержки первичного. Дополнительные члены могут быть добавлены для улучшения отказоустойчивости, при условии соблюдения тех же правил выборов как обычный набор реплик. A readConcern of majority используется mongos, чтобы гарантировать, что осколочные метаданные кластера могут быть прочитаны только после того, как они будут переданы большинству членов набора реплик, а readPreference из nearest используется для маршрутизации запросов на ближайший конфигурационный сервер.