Configurar protocolos do servidor
O MongoDB 3.0 e versões anteriores suportam apenas um único tipo de protocolo de implantação do servidor de configuração que é conhecido como SCCC (Configuração de Conexão de Cluster de Sincronização) legado a partir do MongoDB 3.2. Uma implantação SCCC tem 1 servidor de configuração (somente desenvolvimento) ou 3 servidores de configuração (produção).
O MongoDB 3.2 substitui o protocolo SCCC e oferece suporte a um novo tipo de implantação:Config Servers as Replica Sets (CSRS). Uma implantação CSRS tem os mesmos limites de um conjunto de réplicas padrão, que pode ter 1 servidor de configuração (somente desenvolvimento) ou até 50 servidores (produção) como no MongoDB 3.2. Um mínimo de 3 servidores CSRS é recomendado para alta disponibilidade em uma implantação de produção, mas servidores adicionais podem ser úteis para implantações distribuídas geograficamente.
SCCC (configuração de conexão de cluster de sincronização)
Com o SCCC, os servidores de configuração são atualizados usando um two-phase commit protocolo que requer consenso de vários servidores para uma transação. Você pode usar um único servidor de configuração para fins de teste/desenvolvimento, mas no uso em produção você deve sempre ter 3. Uma resposta prática para o porquê você não pode usar apenas 2 (ou mais de 3) servidores no MongoDB é que a base de código do MongoDB somente suporta 1 ou 3 servidores de configuração para uma configuração SCCC.
Três servidores fornecem uma garantia de consistência mais forte do que dois servidores e permitem a atividade de manutenção (por exemplo, backups) em um servidor de configuração enquanto ainda tem dois servidores disponíveis para seus
mongos para consulta. Mais de três servidores aumentariam o tempo necessário para confirmar dados em todos os servidores. Os metadados do cluster fragmentado precisam ser idênticos em todos os servidores de configuração e são mantidos pela implementação de fragmentação do MongoDB. Os metadados incluem os detalhes essenciais de quais fragmentos contêm atualmente intervalos de documentos (também conhecidos como
chunks ). Em uma configuração SCCC, os servidores de configuração não um conjunto de réplicas, portanto, se um ou mais servidores de configuração estiverem offline, os dados de configuração serão somente leitura - caso contrário, não haverá meios para os dados se propagarem para os servidores de configuração offline quando estiverem online novamente. Claramente 1 servidor de configuração não fornece redundância ou backup. Com 2 servidores de configuração, um cenário de falha potencial é onde os servidores estão disponíveis, mas os dados nos servidores não concordam (por exemplo, um dos servidores teve alguns dados corrompidos). Com 3 servidores de configuração, você pode melhorar o cenário anterior:2/3 servidores podem ser consistentes e você pode identificar o servidor estranho.
CSRS (servidores de configuração como conjuntos de réplicas)
O MongoDB 3.2 descontinua o uso de três
mongod espelhados instâncias para servidores de configuração e, a partir da versão 3.2, os servidores de configuração são (por padrão) implantados como um conjunto de réplicas. Os servidores de configuração do conjunto de réplicas devem usar o mecanismo de armazenamento WiredTiger 3.2+ (ou outro mecanismo de armazenamento que suporte o novo readConcern
leia a semântica de isolamento). O CSRS também não permite algumas opções de configuração de conjunto de réplicas não padrão (por exemplo, arbiterOnly , buildIndexes e slaveDelay ) que não são adequados para o caso de uso de metadados de cluster fragmentado. A implantação do CSRS melhora a consistência e a disponibilidade dos servidores de configuração, pois o MongoDB pode tirar proveito dos protocolos de leitura e gravação do conjunto de réplicas padrão para fragmentação de dados de configuração. Além disso, isso permite que um cluster fragmentado tenha mais de 3 servidores de configuração, pois um conjunto de réplicas pode ter até 50 membros (como no MongoDB 3.2).
Com uma implantação do CSRS, a disponibilidade de gravação depende da manutenção de um quorum de membros que podem ver o primário atual para um conjunto de réplicas. Por exemplo, um conjunto de réplicas de 3 nós exigiria 2 membros disponíveis para manter um primário. Membros adicionais podem ser adicionados para melhorar a tolerância a falhas , sujeito às mesmas regras de eleição como um conjunto de réplicas normal. Uma
readConcern de majority é usado por mongos para garantir que os metadados do cluster fragmentado só possam ser lidos quando forem confirmados para a maioria dos membros do conjunto de réplicas e um readPreference do nearest é usado para rotear solicitações para o servidor de configuração mais próximo. 
