MongoDB na AWS (EBS): 3 réplicas vs. 2 réplicas + Árbitro

Question

Temos um banco de dados Mongo bastante grande em execução na AWS. Atualmente, estamos rodando com um conjunto de réplicas com 3 instâncias. Cada instância possui 5 TB de armazenamento EBS conectado. Isso equivale a mais de US$ 1.000/mês por instância. Além disso, temos um ambiente de produção e de teste (com um terceiro ambiente de "desenvolvimento" em breve). Além disso, esses custos podem explodir no futuro quando/se mudarmos para um ambiente fragmentado.

A questão é: quão necessárias são 3 réplicas em um ambiente AWS?

Ok, ok, ok, já sei que a resposta é "depende". O que procuro são alguns conselhos sobre a melhor forma de avaliar as vantagens e desvantagens. Por exemplo...

1. Considerando que cada volume EBS já possui redundância tripla integrada e que é bastante simples restaurar a partir de um backup, como posso medir a tolerância a falhas adicional de réplicas 2 versus 3.

2. Existem considerações adicionais além da redundância ao considerar as compensações?

3. Alguém tem experiência (boa ou ruim) em executar apenas 2 réplicas + um Árbitro?

Answer 1

1. Considerando que cada volume EBS já possui redundância tripla integrada e que é bastante simples restaurar a partir de um backup, como posso medir a tolerância a falhas adicional de réplicas 2 versus 3.

No que diz respeito ao MongoDB, as principais considerações com apenas dois membros portadores de dados em um conjunto de réplicas de três nós são que, se um desses membros portadores de dados estiver indisponível por qualquer motivo (manutenção planejada ou falha não planejada):

• você não tem mais replicação ativa (há apenas um membro portador de dados restante)
• sua implantação não pode mais reconhecer preocupações de gravação superiores a w:1(por exemplo: w:majorityou w:2)

Esta configuração tem alta disponibilidade em termos de manutenção/eleição de um primário no caso de falha de um único membro, mas o árbitro compromete a redundância de dados se um dos seus membros portadores de dados estiver indisponível. Supondo que você tenha um tempo razoável para restaurar seus backups do EBS (e confie na redundância do EBS), esse pode ser um compromisso aceitável para o seu caso de uso.

2. Existem considerações adicionais além da redundância ao considerar as compensações?

Se o seu código estiver usando MongoDBescreva preocupaçõesmaior que o padrão ( w:1), você desejará adicionar umwtimeoutvalor. Se você não especificar a wtimeoutopção e o nível de preocupação com gravação for inatingível, as operações de gravação serão bloqueadas indefinidamente.

As garantias da AWS sobre infraestrutura redundante geralmente se estendem apenas a falhas em diversas zonas de disponibilidade. Portanto, para maximizar a disponibilidade, você também deve implantar os membros do conjunto de réplicas em diferentes zonas de disponibilidade.

3. Alguém tem experiência (boa ou ruim) em executar apenas 2 réplicas + um Árbitro

Definitivamente, vi resultados ruins em que os usuários não consideraram os pontos acima (principalmente no que diz respeito a preocupações e tempos limite de gravação). Se você planejar (e testar) com essas advertências em mente, poderá obter uma boa experiência.

Além disso, temos um ambiente de produção e de teste (com um terceiro ambiente de "desenvolvimento" em breve).

Definitivamente, há um argumento para ter ambientes de teste e desenvolvimento semelhantes aos de produção, mas uma economia de custos típica seria a implantação de ambientes de especificações mais baixas para desenvolvimento com menos failover do que produção. Para a preparação, talvez você queira implantar ambientes de especificações mais baixas, mas com configuração semelhante, para poder testar cenários de failover realistas. Se você estiver realizando testes de desempenho ou de carga em ambientes de teste, eles deverão ser provisionados com as mesmas especificações da produção.