Se você estiver hospedando seu cluster MongoDB na região leste dos EUA da Amazon AWS, o último mês foi bastante interessante – duas interrupções em quatro semanas testaram a prontidão operacional da sua nuvem implantações. Enquanto escrevo esta postagem no blog, a região de São Paulo também está enfrentando problemas de conectividade. Um número surpreendente de bancos de dados de produção não sobreviveu à interrupção da AWS. Tivemos a oportunidade de conversar com vários clientes do MongoDB na AWS para entender como a interrupção afetou suas implantações. Fiz uma pesquisa rápida com os indivíduos afetados e aqui estão os quatro principais motivos pelos quais as equipes sofreram tempo de inatividade:
-
Executar uma instância autônoma em vez de um conjunto de réplicas
Se você estiver executando um servidor MongoDB de produção, não há desculpa para executar uma instância autônoma em vez de um conjunto de réplicas. Crie um conjunto de réplicas para que você possa ter um secundário para failover em caso de falha primária.
-
Não distribuir réplicas entre zonas de disponibilidade
Certifique-se de distribuir suas réplicas em diferentes zonas de disponibilidade em uma região. Dessa forma, se uma única AZ cair, como aconteceu duas vezes neste mês, seus servidores restantes assumirão o controle e você terá um cluster em funcionamento. Se sua região tiver apenas duas AZs, coloque seu árbitro em uma região diferente. No entanto, isso não o ajudará se toda a região cair. Se você quiser sobreviver a falhas de toda a região da AWS, precisará distribuir seu conjunto de réplicas em diferentes regiões.
-
Não distribuir seus front-ends ou servidores de aplicativos entre zonas de disponibilidade
Certifique-se de distribuir seus front-ends em diferentes zonas de disponibilidade. Não adianta ter seu banco de dados funcionando se seu front-end estiver inativo. Se você tiver problemas de custo, poderá manter um front-end atualizado 'parado' em cada AZ que pode ser ativado em caso de necessidade. Outra opção é ter front-ends de tamanho menor.
-
Conecte-se ao conjunto de réplicas em vez de um único servidor em sua string de conexão
Certifique-se de se conectar ao conjunto de réplicas em vez de um único servidor. A sintaxe é diferente para drivers diferentes, mas verifique a documentação do driver para garantir que você esteja usando a sintaxe correta para se conectar ao conjunto de réplicas em vez de um único servidor. Dessa forma, se houver um failover, o driver MongoDB fará a coisa certa e se conectará ao novo primário.
Na ScaleGrid, automatizamos todos os aspectos operacionais de sua implantação para que você possa se concentrar em seu aplicativo e não se preocupar com as operações. Quando você cria um conjunto de réplicas do MongoDB com ScaleGrid, distribuímos automaticamente as réplicas entre as zonas de disponibilidade. Devido a essa distribuição, todos os nossos clientes conseguiram navegar com segurança pelo problema de inatividade da AWS. Se você estiver interessado em uma leitura mais detalhada sobre os aspectos operacionais do MongoDB, você pode ler minha postagem de blog detalhada anterior – 10 perguntas para fazer e responder ao hospedar o MongoDB na AWS
