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

Question

Temos um banco de dados do Mongo razoavelmente grande em execução no AWS. Atualmente, estamos executando com uma réplica definida com 3 instâncias. Cada instância tem 5 TB de armazenamento EBS anexado. Isso sai para mais de US $ 1000 / mês por instância. Além disso, temos um ambiente de prod e staging (com um terceiro ambiente "dev" em breve). Além disso, esses custos podem explodir no futuro quando / se nos mudarmos para um ambiente fragmentado.

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

Ok ok ok, eu já sei a resposta é "depende". O que estou procurando é um conselho sobre a melhor maneira de pesar as trocas. Por exemplo ...

1. Considerando que cada volume do EBS já possui redundância tripla embutida e que é bastante simples restaurar de um backup, como eu meço a tolerância a falhas adicionada de 2 x 3 réplicas.

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

3. Alguém tem experiência (boa ou má) com a execução de apenas 2 réplicas + um árbitro?

Answer 1

1. Considering that each EBS volume already has triple redundancy built in and that it's fairly straight forward to restore from a backup, how do I measure the added fault tolerance of 2 vs. 3 replicas.

No que diz respeito ao MongoDB, considerações importantes 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 com dados restantes)
• sua implantação não pode mais reconhecer problemas de gravação superiores a w:1 (por exemplo: w:majority ou w:2 )

Essa configuração tem alta disponibilidade em termos de manter / eleger um primário no caso de uma falha de um único membro, mas o árbitro compromete a redundância de dados se um dos seus membros portadores de dados não estiver disponível. Supondo que você tenha um tempo razoável para restauração de seus backups do EBS (e confie na redundância do EBS), isso pode ser um comprometimento aceitável para o seu caso de uso.

2. Are there additional considerations besides redundancy when considering the trade offs?

Se o seu código estiver usando o MongoDB escreva preocupações acima do padrão ( w:1 ) você vai querer adicionar um valor wtimeout . Se você não especificar a opção wtimeout e o nível de preocupação de gravação for inalcançável, as operações de gravação serão bloqueadas indefinidamente.

As garantias da AWS em infraestrutura redundante geralmente só se estendem a falhas em várias zonas de disponibilidade; portanto, para maximizar a disponibilidade, você também deve implantar seus membros do conjunto de réplicas em diferentes zonas de disponibilidade.

3. Does anyone have experience (good or bad) with running only 2 replicas + an Arbiter

Definitivamente, tenho visto resultados ruins em que os usuários não levaram em consideração os pontos acima (especialmente considerando questões de gravação e tempos limite). Se você planeja (e testa) com essas advertências em mente, você deve ser capaz de conseguir o lado da boa experiência.

On top of this, we have both a prod and staging environment (with a third "dev" environment coming soon)

Há definitivamente um argumento para ter ambientes de teste e de desenvolvimento, mas uma economia de custo típica seria a implantação de ambientes de especificação inferiores para o dev com menos failover do que a produção. Para a preparação, você pode querer implantar ambientes de especificação inferiores, mas com configuração semelhante, para poder testar cenários realistas de failover. Se você estiver realizando testes de desempenho ou de carga em ambientes de preparação, eles deverão ser provisionados com as mesmas especificações da produção.