Arquiteturas de implementação do conjunto de réplicas
A arquitetura de umconjunto de réplicas do afeta a capacidade e a funcionalidade do conjunto. Este documento fornece estratégias para implantações de conjuntos de réplicas e descreve arquiteturas comuns.
A implantação do conjunto de réplicas padrão para um sistema de produção é um conjunto de réplicas de três membros. Esses conjuntos fornecem redundância e tolerância a falhas. Evite a complexidade quando possível, mas deixe que os requisitos do seu aplicativo ditem a arquitetura.
Observação
Fora de uma atualização contínua, todos os nós do mongod de um conjunto de réplicas devem usar a mesma versão principal do MongoDB.
Strategies
Determinar o número de membros
Adicione membros em um conjunto de réplicas de acordo com essas estratégias.
Máximo de membros com direito a voto
Um conjunto de réplicas pode ter até 50 membros, mas somente 7 membros com direito ao voto. Se o conjunto de réplicas já tiver 7 membros com direito a voto, os membros adicionais deverão ser membros sem direito a voto.
Implantar um número ímpar de membros
Certifique-se de que o conjunto de réplicas tenha um número ímpar de membros com direito a voto. Um conjunto de réplicas pode ter até sete membros com direito a voto. Se você tiver um número par de membros com direito a voto, implemente outro membro com direito a voto com dados ou, se as restrições proibirem outro membro com direito a voto com dados, um árbitro.
Um árbitro não armazena uma cópia dos dados e requer menos recursos. Como resultado, você pode executar um árbitro em um servidor de aplicativos ou em outro recurso compartilhado. Sem cópia dos dados, talvez seja possível colocar um árbitro em ambientes em que você não colocaria outros membros do conjunto de réplicas. Consulte suas políticas de segurança.
Aviso
Evite implementar mais de um arbiter em um conjunto de réplicas. Consulte Preocupações com vários arbiters.
Para adicionar um árbitro a um conjunto de réplicas existente:
Normalmente, se houver dois ou menos membros portadores de dados no conjunto de réplicas, talvez seja necessário definir primeiro a preocupação de gravação em todo o cluster para o conjunto de réplicas.
Consulte preocupação de gravação em todo o cluster para obter mais informações sobre por que você pode precisar definir a preocupação de gravação em todo o cluster.
Você não precisa alterar a questão de escrita em todo o cluster antes de começar um novo conjunto de réplicas com um arbiter.
Considerar tolerância a falhas
A tolerância a falhas para um conjunto de réplicas é o número de membros que podem ficar indisponíveis e ainda deixar membros suficientes no conjunto para eleger uma primária. Em outras palavras, é a diferença entre o número de membros no conjunto e o majority de membros votantes necessários para eleger uma primária. Sem um primário, um conjunto de réplicas não pode aceitar operações de gravação. A tolerância a falhas é um efeito do tamanho do conjunto de réplicas, mas a relação não é direta. Consulte a tabela a seguir:
Número de membros | Maioria necessária para eleger um novo primário | Tolerância a falhas |
|---|---|---|
3 | 2 | 1 |
4 | 3 | 1 |
5 | 3 | 2 |
6 | 4 | 2 |
Adicionar um membro ao conjunto de réplica nem sempre aumenta a tolerância a falhas. No entanto, nesses casos, membros adicionais podem fornecer suporte para funções dedicadas, como backups ou relatórios.
rs.status() retorna majorityVoteCount para o conjunto de réplicas.
Usar membros ocultos e atrasados para funções dedicadas
Adicione membros ocultos ou atrasados para oferecer suporte a funções dedicadas, como backup ou relatórios.
Aplicativos com muita leitura
Um conjunto de réplicas foi projetado para alta disponibilidade e redundância. Na maioria dos casos, os membros secundários operam sob cargas semelhantes ao primary. Você não deve direcionar as leituras para secundários.
Se você tiver um aplicativo com muita leitura, considere usar Cluster-to-Cluster Sync para replicar dados para outro cluster para leitura.
Para obter mais informações sobre modos de leitura secundários, consulte: secondary e secondaryPreferred.
Adicionar capacidade antes da demanda
Os membros existentes de um conjunto de réplicas devem ter capacidade de sobra para suportar a adição de um novo membro. Sempre adicione novos membros antes que a demanda atual sature a capacidade do conjunto.
Distribuir membros geograficamente
Para proteger seus dados em caso de falha do data center, mantenha pelo menos um membro em um data center alternativo. Se possível, use um número ímpar de data centers e escolha uma distribuição de membros que maximize a probabilidade de que, mesmo com a perda de um data center, os membros restantes do conjunto de réplicas possam formar uma maioria ou, no mínimo, fornecer uma cópia de seus dados.
Observação
A distribuição de membros do conjunto de réplicas em dois centros de dados fornece benefícios de um único centro de dados. Em uma distribuição de dois centros de dados ,
Se um dos centros de dados ficar inativo, os dados ainda estarão disponíveis para leituras, diferentemente de uma distribuição de centro de dados único.
Se o centro de dados com uma minoria dos membros ficar inativo, o conjunto de réplicas ainda pode servir operações de gravação, bem como operações de leitura.
No entanto, se o centro de dados com a maioria dos membros cair, o conjunto de réplicas se tornará somente leitura.
Se possível, distribua membros em pelo menos três data centers. Para conjuntos de réplicas do servidor de configuração (CSRS), a prática recomendada é distribuir por três (ou mais, dependendo do número de membros) centros. Se o custo do terceiro data center for proibitivo, uma possibilidade de distribuição é distribuir uniformemente os membros da propriedade de dados nos dois data centers e armazenar o membro restante na nuvem, se a política da sua empresa permitir.
Para garantir que os membros em seu centro de dados principal sejam eleitos primários antes dos membros no centro de dados alternativo, defina o dos membros no centro de dados alternativo para ser menor do que o dos membros no centro de dados members[n].priority primário.
Para obter mais informações, consulte Conjuntos de réplicas distribuídos em dois ou mais data centers
Operações direcionadas com conjuntos de tags
Use conjuntos de tags de conjuntos de réplicas para direcionar operações de leitura para nós específicos, ou para personalizar a preocupação de gravação para solicitar a confirmação de nós específicos.
Use os registros no diário para se proteger contra falhas de energia
O MongoDB habilita o registro no diário por padrão. O registro no diário protege contra a perda de dados em caso de interrupções de serviço, como falhas de energia e reinicializações inesperadas.
Nomes do host
Importante
Para evitar atualizações de configuração devido a alterações de endereço IP, use nomes de host DNS em vez de endereços IP. É particularmente importante usar um nome de host DNS em vez de um endereço IP ao configurar membros de conjunto de réplicas ou membros de cluster fragmentado.
Use nomes de host em vez de endereços IP para configurar cluster em um horizonte de rede dividido. Começando no MongoDB 5.0, nós configurados apenas com um endereço IP falham na validação de inicialização e não são iniciados.
Nomenclatura dos conjuntos de réplicas
Se seu aplicativo se conectar a mais de um conjunto de réplicas, cada conjunto deverá ter um nome distinto. Alguns drivers agrupam conexões de conjunto de réplicas por nome de conjunto de réplicas.
Padrões de implantação
Os documentos a seguir descrevem padrões comuns de implantação de conjuntos de réplicas. Outros padrões são possíveis e eficazes, dependendo dos requisitos do aplicativo. Se necessário, combine recursos de cada arquitetura em sua própria implantação:
- Três conjuntos de réplicas para membros
- Os conjuntos de réplica de três membros fornecem a arquitetura mínima recomendada para um conjunto de réplicas.
- Conjuntos de réplicas distribuídos em dois ou mais data centers
- Os conjuntos distribuídos geograficamente incluem membros em várias localizações para proteger contra falhas específicas das instalações, como falta de energia.