Para escrever código de aplicativo que aproveite os recursos do MongoDB e lide normalmente com eleições de conjuntos de réplicas, você deve:
Instale as bibliotecas de cliente mais recentes.
Use uma string de conexão que especifique todos os hosts.
Use leituras e gravações repetíveis.
Use um write concern
majoritye um read concern que faça sentido para seu aplicativo.Lide com erros em seu aplicativo.
Instale as bibliotecas de clientes mais recentes
Primeiro, instale as bibliotecas de cliente mais recentes para seu idioma a partir das Bibliotecas de cliente do MongoDB. As bibliotecas de clientes conectam e retransmitem queries do seu aplicativo para o seu banco de dados. O uso das bibliotecas de cliente mais recentes ativa os recursos mais recentes do MongoDB .
Em seguida, em seu aplicativo, importe a dependência:
Cadeias de conexão
Use uma connection string que especifica todos os hosts em seu sistema para conectar seu aplicativo ao seu banco de dados. Se o sistema executar uma eleição de conjunto de réplicas e um novo primário for eleito, uma connection string que especifica todos os hosts em seu sistema descobrirá o novo primário sem lógica de aplicativo.
Você pode especificar todos os hosts em seu sistema usando:
A string de conexão também pode especificar opções, principalmente retryWrites e writeConcern.
Dica
Para obter ajuda para formatar sua string de conexão, consulte Conectar-se a uma implantação usando uma biblioteca de cliente MongoDB.
Use sua cadeia de conexão para instanciar um cliente MongoDB em seu aplicativo:
Escrituras e leituras retráteis
Observação
A partir do MongoDB versão 3.6 e com bibliotecas de cliente compatíveis com4.2, o MongoDB tenta novamente gravações e leituras uma vez por padrão.
Gravações repetíveis
Use gravações repetíveis para repetir determinadas operações de gravação uma única vez se elas falharem.
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, ou
Um comando inválido.
Dica
Para obter mais informações sobre como habilitar gravações repetíveis, consulte Habilitar gravações repetíveis.
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 a partir da versão 3.6 do MongoDB e com bibliotecas de cliente compatíveis com4.2. Você não precisa configurar seu aplicativo 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 referência de leitura e gravação 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 para fornecer acesso mais rápido a esses dados.
Escreva preocupação
Você pode definir o nível de write concern do seu conjunto de réplicas por meio do URI da connection string. Utilize uma write concern do majority para garantir que seus dados sejam gravados com sucesso no seu banco de dados e persistam. Esse é o padrão recomendado e suficiente para a maioria dos casos de uso.
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:
O parâmetro de string de conexão
wtimeoutMSpara todas as gravações, ouA opção tempo-limite para uma única operação de gravação.
Se você utiliza ou não um limite de tempo e o valor que você utiliza depende do contexto do aplicativo.
Dica
Para obter mais informações sobre como definir níveis de preocupação de gravação , consulte Opções de write concern.
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 nunca será concluída.
Read concern
Você pode definir o nível de preocupação de leitura do seu conjunto de réplicas por meio do URI da string de conexão . A preocupação de leitura ideal depende dos requisitos do aplicação , mas o padrão é suficiente para a maioria dos casos de uso. Não é necessário nenhum parâmetro de string de conexão para utilizar as preocupações de read concern.
Especificar uma referência de leitura pode melhorar as garantias em torno dos dados que a aplicação recebe do reconhecimento de data center.
Dica
Para obter mais informações sobre como definir níveis de read concern, consulte Opções de read concern.
Observação
A combinação específica de write concern e preocupação de leitura que seu aplicação usa afeta as garantias de ordem de operação. Isso é chamado de consistência causal. Para obter mais informações sobre garantias de consistência causal, consulte Consistência causal e read and write concern.
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 da sua biblioteca cliente para obter detalhes sobre o erro.
Por exemplo, se um aplicativo tentar inserir um documento com um _id duplicado, sua biblioteca do cliente 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, 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 aplicativo detecta o erro, 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 a um usuário que uma ação não pode ser concluída.
Escreva em um banco de dados de backup. 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
Retornar um erro pode ser um comportamento desejável quando uma operação nunca seria concluída e bloquearia seu aplicativo de executar novas operações. Você pode usar o método maxTimeMS para colocar um limite de tempo em operações individuais, retornando um erro para que seu aplicativo manipule se esse limite de tempo for excedido.
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.
Aplicação de exemplo resiliente
O aplicativo de exemplo a seguir reúne as recomendações para a criação de aplicativos resilientes.
O aplicação é uma API simples de registros de usuário que expõe dois endpoints em http://localhost:3000:
Método | Endpoint | Descrição |
|---|---|---|
|
| Obtém uma lista de nomes de usuário de uma coleção do |
|
| Exige um |