Ao criar um aplicação de importância crítica, é importante se preparar para eventos inesperados que podem ocorrer na produção. Isso inclui queries lentas inesperadas, índices ausentes ou um aumento acentuado no volume do volume de trabalho.
O MongoDB Atlas ajuda você a criar um aplicação resiliente, fornecendo recursos prontos para o uso que permitem que você se prepare de forma proativa e responda de forma reativa às situações. Para criar um aplicação resiliente, recomendamos que você configure a implantação do MongoDB com as seguintes práticas recomendadas de resiliência de cluster e aplicação e do lado do cliente .
Resiliência do cluster
Para melhorar a resiliência do cluster, atualize-o para o MongoDB 8.0. O MongoDB 8.0 introduz as seguintes melhorias de desempenho e novas funcionalidades relacionadas à resiliência:
Operation rejection filters to reactively mitigate expensive queries
Cluster-level timeouts for proactive protection against expensive read operations
Better workload isolation with the moveCollection command
Gerenciamento de memória aprimorado
Para executar seu aplicação com segurança na produção, é importante garantir que a utilização da memória permita o headroom. Se um nó ficar sem memória disponível, ele pode se tornar suscetível ao Linux Out of Memory Killer, que encerra o processo mongod.
O MongoDB 8.0 usa um TCMalloc atualizado para todas as implantações automaticamente, o que reduz o crescimento médio da fragmentação da memória ao longo do tempo. Essa fragmentação menor melhora a estabilidade operacional durante os carregamentos de pico e resulta em uma utilização geral da memória aprimorada.
Filtros de rejeitar operação
Uma operação não intencional de uso intensivo de recursos pode causar problemas na produção se você não lidar com ela imediatamente.
O MongoDB 8.0 permite minimizar o impacto dessas operações usando filtros de aceitação de operações. Os filtros de exclusão de operações permitem configurar o MongoDB para rejeitar a execução de queries até que você reative as queries com essa forma de query.
Em outras palavras, depois de identificar uma query lenta, não é necessário esperar que as equipes de aplicação corrijam suas queries para conter o impacto da query lenta. Em vez disso, quando você notar uma query de baixo desempenho em seu Analisador de Query, Painel de Desempenho em Tempo Real ou logs de query, você pode definir um filtro de rejeitação para essa forma de query. O MongoDB então impede que novas instâncias dessa forma de query recebida sejam executadas. Depois de corrigir a query, você pode reativar a forma de query.
Você deve usar um filtro de aceitação de operação se quiser:
Contenha o impacto de queries lentas rapidamente enquanto a correção está em andamento.
Priorize cargas de trabalho mais importantes durante períodos de sobrecarga rejeitando consultas menos importantes.
Dê ao cluster tempo para se recuperar se estiver próximo da utilização máxima de recursos.
Identificar e rejeitar queries lentas na UI do Atlas
Para utilizar um filtro de aceitação de operação na UI do Atlas :
No Atlas, vá para a página Clusters do seu projeto.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Na barra lateral, clique em Clusters sob o título Database.
A página Clusters é exibida.
Go Vá para o Analisador de query do cluster especificado dentro do projeto atual.
Clique no nome do cluster para abrir a barra lateral Cluster.
Clique em Query Insights na barra lateral Cluster.
Clique na aba Query Profiler.
Rejeite operações de uma forma de query específica .
Use setQuerySettings in your db.adminCommand() method to pass in the queryShapeHash, which specifies the query shape you want to reject.
Observação
You must have the atlasAdmin role to use setQuerySettings.
Para obter um exemplo, consulte Bloquear queries lentas com filtros de Rejeição de Operação.
Monitore suas queries após a rejeitação ou o tempo-limite
Você pode monitorar como suas queries são executadas posteriormente em Métricas na barra lateral Cluster:
No Atlas, vá para a página Clusters do seu projeto.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Na barra lateral, clique em Clusters sob o título Database.
A página Clusters é exibida.
Tempo limite em nível de cluster para operações de leitura
É importante garantir que seu processo de desenvolvimento considere cuidadosamente a eficiência das queries antes que elas cheguem à produção. Exceções sempre podem ocorrer, mas ter uma mitigação proativa contra queries ineficientes pode ajudar a evitar problemas de desempenho do cluster.
With MongoDB 8.0, you can protect your queries from unindexed operations with the server-side defaultMaxTimeMS coming into the cluster. If an operation exceeds this timeout, MongoDB cancels the operation to prevent queries from running too long and holding on to resources. This allows you to:
Transfira a responsabilidade de definir timeouts de equipes de aplicação individuais para equipes focados no banco de dados de dados.
Minimize o impacto de uma verificação de collection se a query não tiver um índice.
Tenha uma mitigação de última rodada contra operações caras que chegam à produção.
If you have queries that require a different timeout, such as analytics queries, you can override them by setting the operation-level timeout with the maxTimeMS method.
Definir o tempo limite padrão para operações de leitura na API de administração do Atlas
To set the defaultMaxTimeMS parameter through the Atlas Administration API, see Update Advanced Configuration Options for One Cluster.
Definir o tempo limite padrão para operações de leitura na UI do Atlas
To set the defaultMaxTimeMS parameter in the Atlas UI:
No Atlas, vá para a página Clusters do seu projeto.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Na barra lateral, clique em Clusters sob o título Database.
A página Clusters é exibida.
Navegue até suas opções de configuração.
Se você tiver um cluster existente, navegue até a página Editar Cluster .
Se você estiver criando um novo cluster, no menu suspenso Select a version , selecione MongoDB 8.0.
Clique em Additional Settings.
Role para baixo e clique em More Configuration Options.
To view the behavior of killed operations, see Monitor Your Queries After Rejection or Timeout. To learn more, see defaultMaxTimeMS and Set Default Timeout for Read Operations.
Isolar o impacto de collections ativas e não fragmentadas
A fragmentação permite que você escale seu cluster horizontalmente. Com o MongoDB, você pode fragmentar algumas collections e, ao mesmo tempo, permitir que outras collections no mesmo cluster permaneçam não fragmentadas. Quando você cria um novo banco de dados de dados, o fragmento no cluster com a menor quantidade de dados é escolhido como o fragmento primário desse banco de dados por padrão. Todas as collections não fragmentadas desse banco de dados de dados residem nesse fragmento primário por padrão. Isso pode causar um aumento no tráfego para o fragmento primário à medida que sua carga de trabalho cresce, especialmente se o crescimento do volume de trabalho se concentrar nas coleções não fragmentadas do fragmento primário.
To distribute this workload better, MongoDB 8.0 allows you to move an unsharded collection to other shards from the primary shard with the moveCollection command. This allows you to place active, busy collections onto shards with less expected resource usage. With this, you can:
Otimize o desempenho em volumes de trabalho maiores e complexos.
Obtenha uma melhor utilização dos recursos.
Distribua a data de forma mais uniforme entre os fragmentos.
Recomendamos isolar sua coleção nas seguintes circunstâncias:
Se o seu fragmento primário tiver uma carga de trabalho significativa devido à presença de várias collections não fragmentadas de alta taxa de transferência.
Você antecipa uma coleção não fragmentada para experimentar um crescimento futuro, o que pode se tornar um gargalo para outras coleções.
Você está executando um design de implantação de uma collection por cluster e deseja isolar esses clientes com base em prioridade ou volumes de trabalho.
Seus shards têm uma quantidade mais do que proporcional de dados devido ao número de collections não fragmentadas localizadas neles.
To learn how to move an unsharded collection with mongosh, see Move a Collection.
Melhores práticas de aplicativos e do lado do cliente
Você pode configurar os recursos de seus sistemas do MongoDB e as bibliotecas de drivers para criar um aplicativo resiliente que possa resistir a interrupções de rede e eventos de failover. Para escrever código de aplicativo que aproveite ao máximo os recursos sempre ativos do MongoDB Atlas, você deve executar as seguintes tarefas:
Use a
majoritywrite concern and a read concern that makes sense for your application.Handle errors in your application.
Instale as bibliotecas de clientes mais recentes
Install the latest client libraries for your language from MongoDB Client Libraries. Client libraries connect and relay queries from your application to your database. Using the latest client libraries enables the latest MongoDB features.
Em seguida, em seu aplicativo, importe a dependência:
Cadeias de conexão
Observação
Atlas provides a pre-configured connection string. For steps to copy the pre-configured string, see Atlas-Provided Connection Strings.
Utilize uma string de conexão que especifica todos os nós no seu cluster do Atlas para conectar seu aplicativo ao seu banco de dados. Se o cluster executar uma eleição de conjunto de réplicas e um novo primário for eleito, uma cadeia de conexão que especifica todos os nós no cluster descobrirá o novo primário sem lógica de aplicativo.
Em cluster Atlas Infinite, a camada de armazenamento coordena o failover em vez de uma eleição entre os nós do cluster, e uma string de conexão que especifica todos os nós descobre o novo primário da mesma maneira. Para saber mais, consulte Replicação e Failover.
Você pode especificar todos os nós em seu cluster usando:
o formato de conexão DNS Seedlist (recomendado com o Atlas).
The connection string can also specify options, notably retryWrites and writeConcern.
O Atlas pode gerar uma connection string SRV otimizada para clusters fragmentados por meio dos balancers de carga do seu serviço de private endpoints. Quando você utiliza uma cadeia de conexão otimizada, o Atlas limita o número de conexões por mongos entre seu aplicativo e seu cluster fragmentado. As conexões limitadas por mongos melhoram o desempenho durante picos nas contagens de conexões.
Para saber mais sobre strings de conexão otimizadas para clusters fragmentados por trás de um ponto de extremidade privado, consulte Como posso otimizar o desempenho da conexão para clusters fragmentados usando pontos de extremidade privados?.
Cadeias de conexão fornecidas pelo Atlas
Se você copiar a cadeia de conexão da interface do cluster do Atlas, a cadeia de conexão será pré-configurada para o cluster, usará o formato DNS Seedlist e incluirá as opções recomendadas de retryWrites e w (write concern) para resiliência.
Para copiar o URI da cadeia de conexão do Atlas:
No Atlas, vá para a página Clusters do seu projeto.
Se ainda não tiver sido exibido, selecione a organização que contém seu projeto no menu Organizations na barra de navegação.
Se ainda não estiver exibido, selecione o projeto desejado no menu Projects na barra de navegação.
Na barra lateral, clique em Clusters sob o título Database.
A página Clusters é exibida.
Copie o URI da string de conexão .
Copie a cadeia de conexão ou o exemplo completo do driver no código do seu aplicativo. Você deve fornecer as credenciais de usuário de banco de dados.
Observação
This guide uses SCRAM authentication through a connection string. To learn about using X.509 certificates to authenticate, see X.509.
Use sua cadeia de conexão para instanciar um cliente MongoDB em seu aplicativo:
Escrituras e leituras retráteis
Observação
O MongoDB tenta novamente gravações e leituras uma vez por padrão.
Gravações repetíveis
Use retryable writes to retry certain write operations a single time if they fail. If you copied your connection string from Atlas, it includes "retryWrites=true". If you are providing your own connection string, include "retryWrites=true" as a query parameter.
Repetir gravações exatamente uma vez é a melhor estratégia para lidar com erros transitórios de rede e eleições de conjunto de réplicas nas quais o aplicativo não consegue encontrar temporariamente um nó primário íntegro. Se a nova tentativa for bem-sucedida, a operação como um todo será bem-sucedida e nenhum erro será retornado. Se a operação falhar, provavelmente será devido a:
Um erro de rede duradouro
Um comando inválido
Quando uma operação falha, seu aplicativo precisa lidar com o próprio erro.
Leituras repetíveis
As operações de leitura são automaticamente repetidas uma única vez se falharem. Nenhuma configuração adicional é necessária para tentar ler novamente.
Escreva e leia a preocupação
Você pode ajustar a constância e a disponibilidade do seu aplicativo usando write concern e read concern. Preocupações mais rigorosas implicam que as operações de banco de dados aguardam por garantias mais fortes de consistência de dados, enquanto o afrouxamento dos requisitos de consistência fornece maior disponibilidade.
Exemplo
Se a sua aplicação lida com saldos monetários, a consistência é extremamente importante. Você pode usar majority preocupações de gravação e leitura para garantir que nunca leia dados obsoletos ou dados que possam ser revertidos.
Como alternativa, se o aplicativo registrar dados de temperatura de centenas de sensores a cada segundo, talvez você não esteja preocupado se ler os dados que não incluem as leituras mais recentes. Você pode perder os requisitos de consistência e fornecer acesso mais rápido a esses dados.
Escreva preocupação
You can set the write concern level of your Atlas replica set through the connection string URI. Use a majority write concern to ensure your data is successfully written to your database and persisted. This is the recommended default and sufficient for most use cases. If you copied your connection string from Atlas, it includes "w=majority".
Quando você usa uma write concern que exige confirmação, como majority, também pode especificar um limite de tempo máximo para que as gravações atinjam esse nível de confirmação:
The wtimeoutMS connection string parameter for all writes, or
The wtimeout option for a single write operation.
Se você utiliza ou não um limite de tempo e o valor que você utiliza depende do contexto do seu aplicativo.
Em um cluster Atlas Infinite, a camada de armazenamento reconhece suas gravar, portanto, os valores de write concern que você pode definir são diferentes. Para aprender mais, consulte Write Concern em clusters Atlas Infinite.
Importante
Se você não especificar um limite de tempo para gravações e o nível de write concern for inatingível, a operação de gravação travará indefinidamente.
Read concern
You can set the read concern level of your Atlas replica set through the connection string URI. The ideal read concern depends on your application requirements, but the default is sufficient for most use cases. No connection string parameter is required to use default read concerns.
Especificar uma questão de leitura pode melhorar as garantias em torno dos dados que a sua aplicação recebe do Atlas.
Observação
The specific combination of write and read concern your application uses has an effect on order-of-operation guarantees. This is called causal consistency. For more information on causal consistency guarantees, see Causal Consistency and Read and Write Concerns.
Error Handling
Comandos inválidos, interrupções de rede e erros de rede que não são manipulados por gravações repetíveis retornam erros. Consulte a documentação da API do driver para obter detalhes de erro.
Por exemplo, se um aplicativo tentar inserir um documento que contém um valor _id que já é utilizado na coleção do banco de dados, seu driver retornará um erro que inclui:
Sem o tratamento adequado de erros, um erro pode bloquear seu aplicativo de processar solicitações até que ele seja reiniciado.
Seu aplicativo deve lidar com erros sem travamentos ou efeitos colaterais. No exemplo anterior de um aplicativo inserindo um _id duplicado em uma coleção, este aplicativo pode lidar com erros como segue:
A operação de inserção neste exemplo gera um erro "duplicate key" na segunda vez em que é invocada porque o campo _id deve ser exclusivo. O erro é detectado, o cliente é notificado e o aplicativo continua em execução. No entanto, a operação de inserção falha e cabe a você decidir se deseja mostrar uma mensagem ao usuário, repetir a operação ou fazer outra coisa.
Você deve sempre registrar erros. Estratégias comuns para erros de processamento adicionais incluem:
Devolva o erro ao cliente com uma mensagem de erro. Essa é uma boa estratégia quando você não consegue resolver o erro e precisa informar ao usuário que uma ação não pode ser concluída.
Escreva em um banco de dados de cópia de segurança. Essa é uma boa estratégia quando você não consegue resolver o erro, mas não quer correr o risco de perder os dados da solicitação.
Tente novamente a operação além da tentativa única padrão. Essa é uma boa estratégia quando você pode resolver a causa de um erro programaticamente e, em seguida, tentar novamente.
Você deve selecionar as melhores estratégias para o contexto do seu aplicativo.
Exemplo
No exemplo de um erro de chave duplicada, você deve registrar o erro, mas não repetir a operação porque ela nunca terá êxito. Em vez disso, você pode gravar em um banco de dados de fallback e revisar o conteúdo desse banco de dados posteriormente para garantir que nenhuma informação seja perdida. O usuário não precisa fazer mais nada e os dados são gravados, então você pode optar por não enviar uma mensagem de erro para o cliente.
Planejamento de erros de rede
Returning an error can be desirable behavior when an operation would otherwise hang indefinitely and block your application from executing new operations. You can use the maxTimeMS method to place a time limit on individual operations, returning an error for your application to handle if that time limit is exceeded.
O limite de tempo que você coloca em cada operação depende do contexto desta operação.
Exemplo
Se sua aplicação ler e exibir informações simples do produto de uma coleção inventory , você poderá ter certeza razoável de que essas operações de leitura levam apenas um momento. Uma query de execução incomumente longa é um bom indicador de que há um problema de rede duradouro. Definir maxTimeMS nessa operação para 5000, ou 5 segundos, significa que seu aplicativo recebe comentários assim que você tiver certeza de que há um problema de rede.
Testar failover
No espírito dos testes de caos, o Atlas realizará eleições de conjunto de réplicas automaticamente para manutenção periódica e certas alterações de configuração.
Para verificar se seu aplicativo é resiliente às eleições de conjunto de réplicas, teste o processo de failover simulando um evento de failover.
Aplicação de exemplo resiliente
O aplicativo de exemplo reúne as seguintes recomendações para garantir a resiliência contra interrupções de rede e eventos de failover:
Use a cadeia de conexão fornecida pelo Atlas com gravações repetíveis, write concern majoritária e read concern padrão.
Specify an operation time limit with the maxTimeMS method. For instructions on how to set
maxTimeMS, refer to your specific Driver Documentation.Lidar com erros de chaves duplicadas e tempos-limite.
O aplicativo é uma API HTTP que permite aos clientes criar ou listar registros de usuário. Ele expõe um ponto de extremidade que aceita solicitações GET e POST http://localhost:3000:
Método | Endpoint | Descrição |
|---|---|---|
|
| Obtém uma lista de nomes de usuário de uma coleção do |
|
| Exige um |