MongoDB
 sql >> Base de Dados >  >> NoSQL >> MongoDB

Comparando padrões de implantação para o MongoDB

A implantação do MongoDB em produção só pode realmente funcionar se o padrão de implantação correto for seguido. A implantação de um conjunto de réplicas em um único host não garante a alta disponibilidade dos dados. Lidar com big data requer extensa pesquisa e implementações ideais, seja combinando as opções disponíveis ou escolhendo aquela com os benefícios mais promissores.

Os padrões de implantação do MongoDB incluem:

  1. Conjuntos de réplicas de três membros
  2. Conjuntos de réplicas distribuídos em dois ou mais data centers.

Três conjuntos de réplicas de membros

A replicação é uma estratégia de dimensionamento para o MongoDB que aprimora a alta disponibilidade de dados. Um conjunto de réplicas envolve:

  1. Um nó primário:responsável por todas as operações de taxa de transferência de gravação e também pode ser lido.
  2. Nós secundários:só podem ser usados ​​para operações de leitura, mas podem ser eleitos como primários caso o existente falhe. Eles obtêm suas atualizações de dados de um oplog gerado pelo membro principal do conjunto.
  3. Árbitro. Usado para facilitar a eleição de um primário caso haja um número par de membros do conjunto de réplicas. Ele não hospeda nenhuma cópia dos dados.

Os benefícios de um conjunto de réplicas só podem ser alcançados com um número mínimo de três membros com a seguinte arquitetura:

Primário-Secundário-Secundário

Este é o mais recomendado, pois possui maior tolerância a falhas e aborda as limitações de adicionar um terceiro membro portador de dados, como custo.

Esta implantação sempre fornecerá duas cópias completas além dos dados primários, garantindo alta disponibilidade. A falha do primário acionará o conjunto de réplicas para eleger um novo primário e a operação de veiculação será retomada normalmente. Se o antigo primário se tornar ativo, ele será categorizado como membro secundário.

Durante o processo de eleição, os membros sinalizam entre si por meio de uma pulsação e não há operações de gravação ocorrendo durante esse período

Após o processo eleitoral assumimos a arquitetura a reformar como:

Árbitro-Primário-Secundário

Isso garante que o conjunto de réplicas permaneça disponível mesmo se o primário ou secundário estiver indisponível, facilitando o processo de eleição de um secundário para um primário. Os árbitros não carregam nenhuma cópia dos dados, portanto, exigem menos recursos para gerenciar.

Uma limitação com esta implantação é; sem redundância, pois existem apenas dois membros portadores de dados:primário e secundário. Isso resulta em uma menor tolerância a falhas.

A tolerância a falhas deve ser capaz de garantir:

  1. Disponibilidade de gravação:a maioria dos membros do conjunto de réplicas de votação é necessária para manter ou eleger o principal responsável pelas operações de gravação.
  2. Redundância de dados:a gravação pode ser reconhecida por vários membros para evitar reversões

A configuração Primary-Secondary-Arbiter suporta o aspecto de disponibilidade de gravação apenas de modo que, se um único membro do conjunto estiver indisponível, um primário ainda poderá ser mantido.

No entanto, a falha no suporte ao segundo aspecto resultará em algumas consequências operacionais se o membro secundário ficar indisponível:

  • Não haverá replicação ativa, especialmente se o secundário estiver offline por muito tempo. Quando o secundário fica off-line por muito tempo, ele pode cair do oplog, forçando-o a ressincronizá-lo durante a reinicialização.
  • A redundância de dados será sabotada, forçando a operação de gravação a ser reconhecida apenas pelo primário atual.
  • A opção de maior preocupação não fornecerá os dados mais recentes para os aplicativos conectados e processos internos. Esse é o caso quando sua configuração espera que as gravações solicitem confirmação de maioria, portanto, é bloqueada até que a maioria dos membros portadores de dados esteja disponível.
  • A migração de fragmentos entre fragmentos também será comprometida se o conjunto de réplicas fizer parte de um cluster fragmentado.
  • Pressão no cache do mecanismo de armazenamento WiredTiger se ocorrerem reversões e o ponto de confirmação principal não puder ser avançado.

Para evitar essas consequências, pode-se optar por uma configuração Primário-Secundário-Secundário , pois aumenta a tolerância a falhas.

Observação:a tolerância a falhas não ocorre apenas em caso de falha, mas também algumas operações do sistema, como atualização de software e manutenção normal, podem forçar um membro a ficar indisponível brevemente.

Conjuntos de réplicas distribuídos em dois ou mais data centers

A alta disponibilidade pode ser elevada a outro nível distribuindo membros do conjunto de réplicas em data centers geograficamente distintos. Essa abordagem aumentará a redundância, além de garantir alta tolerância a falhas caso algum data center fique indisponível.

Se todos os membros estiverem localizados em um único data center, o conjunto de réplicas estará suscetível a falhas no data center, como transientes de rede e falta de energia.

É aconselhável manter pelo menos um membro em um data center alternativo, usar um número ímpar de centros de dados e selecionar uma distribuição de membros que ofereça a maioria para eleição ou, no mínimo, forneça uma cópia dos dados em caso de falha.

A configuração deve garantir que, se algum datacenter ficar inativo, o conjunto de réplicas permaneça gravável, pois os membros restantes podem realizar uma eleição.

Distribua seus dados pelo menos em três data centers.

Os membros podem estar limitados a recursos ou ter restrições de rede, tornando-os inadequados para se tornarem primários em caso de failover. Você pode configurar esses membros para não se tornarem primários dando-lhes prioridade 0.

Os membros de um datacenter podem ter uma prioridade mais alta do que outros datacenters para dar a eles uma prioridade de votação, de modo que possam eleger os membros primários antes dos membros em outros datacenters.

Todos os membros do conjunto de réplicas devem poder se comunicar entre si.

Conclusão

Os benefícios da replicação podem ser elevados a um status mais promissor, distribuindo os membros em vários data centers. Isso aumenta essencialmente a tolerância a falhas, além de garantir a redundância de dados. Os membros do conjunto de réplicas quando distribuídos em dois ou mais datacenters oferecem benefícios em um único datacenter, como:

Se um dos datacenters ficar inativo, os dados ainda estarão disponíveis para leituras, diferentemente de uma distribuição de datacenter único.

As operações de gravação ainda podem ser reconhecidas sempre que um data center com membros minoritários ficar inativo.

As operações de leitura ainda podem ser possíveis se o data center com a maioria dos membros votantes ficar inativo, diferentemente do caso do data center único.