Crie um aplicativo resiliente com o MongoDB Atlas

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.

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.

Com o MongoDB 8.0, você pode proteger suas queries de operações não indexadas com o defaultMaxTimeMS do lado do servidor que entra no cluster. Se uma operação exceder esse tempo limite, o MongoDB cancelará a operação para evitar que as queries sejam muito longas e retenham os recursos. Isso permite que você:

• 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.

Se você tiver queries que exigem um tempo limite diferente, como queries de analítica, poderá substituí-las definindo o tempo limite de nível de operação com o método maxTimeMS .

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.

Para distribuir melhor esse volume de trabalho, o MongoDB 8.0 permite mover uma coleção não fragmentada do fragmento primário para outros shards com o comando moveCollection . Isso permite que você coloque collections ativas e sobrecarregadas em shards com um uso menor de recursos. Com isso, você pode:

• 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.

Para saber como mover uma collection não fragmentada com mongosh, consulte Mover uma collection.

Instale os drivers mais recentes

Instale os drivers mais recentes do seu idioma a partir de Drivers do MongoDB. Os drivers conectam e retransmitem queries da sua aplicação para o seu banco de dados de dados . O uso dos drivers mais recentes ativa os recursos mais recentes do MongoDB .

Em seguida, em seu aplicativo, importe a dependência:

<dependencies>
    <dependency>
        <groupId>org.mongodb</groupId>
        <artifactId>mongodb-driver-sync</artifactId>
        <version>4.0.1</version>
    </dependency>
</dependencies>

dependencies {
  compile 'org.mongodb:mongodb-driver-sync:4.0.1'
}

// Latest 'mongodb' version installed with npm
const MongoClient = require('mongodb').MongoClient;

# Install the latest 'pymongo' version with pip and
# import MongoClient from the package to establish a connection.
from pymongo import MongoClient

Cadeias de conexão

Utilize uma cadeia 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.

Você pode especificar todos os nós em seu cluster usando:

• o formato de cadeia de conexão padrão ou

• o formato de conexão DNS Seedlist (recomendado com o Atlas).

A cadeia de conexão também pode especificar opções, principalmente retryWrites e writeConcern.

O Atlas pode gerar uma cadeia de conexãoSRV otimizada para clusters fragmentados usando os balanceadores de carga do seu serviço de pontos de extremidade privados. 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 cadeias de conexão otimizadas para clusters fragmentados por trás de um ponto de extremidade privado, consulte Aprimorar o desempenho da conexão dos clusters fragmentados por trás de um ponto de extremidade privado.

// Copy the connection string provided by Atlas
String uri = <your Atlas connection string>;
// Instantiate the MongoDB client with the URI
MongoClient client = MongoClients.create(uri);

// Copy the connection string provided by Atlas
const uri = <your Atlas connection string>;
// Instantiate the MongoDB client with the URI
const client = new MongoClient(uri, {
    useNewUrlParser: true,
    useUnifiedTopology: true
});

# Copy the connection string provided by Atlas
uri = <your Atlas connection string>
# Pass your connection string URI to the MongoClient constructor
client = MongoClient(uri)

Escrituras e leituras retráteis

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.

Error Handling

Comandos inválidos, interrupções de rede e erros de rede que não são tratados por gravações repetíveis retornam erros. Consulte a documentação da API do seu driver para obter detalhes sobre o 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:

Unable to insert due to an error: com.mongodb.MongoWriteException:
E11000 duplicate key error collection: <db>.<collection> ...

{
    "name": : "MongoError",
    "message": "E11000 duplicate key error collection on: <db>.<collection> ... ",
    ...
}

pymongo.errors.DuplicateKeyError: E11000 duplicate key error collection: <db>.<collection> ...

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:

// Declare a logger instance from java.util.logging.Logger
private static final Logger LOGGER = ...
...
try {
    InsertOneResult result = collection.insertOne(new Document()
        .append("_id", 1)
        .append("body", "I'm a goofball trying to insert a duplicate _id"));
    // Everything is OK
    LOGGER.info("Inserted document id: " + result.getInsertedId());
// Refer to the API documentation for specific exceptions to catch
} catch (MongoException me) {
    // Report the error
    LOGGER.severe("Failed due to an error: " + me);
}

...
collection.insertOne({
    _id: 1,
    body: "I'm a goofball trying to insert a duplicate _id"
})
.then(result => {
    response.sendStatus(200) // send "OK" message to the client
},
err => {
    response.sendStatus(400); // send "Bad Request" message to the client
});

...
try:
    collection.insert_one({
        "_id": 1,
        "body": "I'm a goofball trying to insert a duplicate _id"
    })
    return {"message": "User successfully added!"}
except pymongo.errors.DuplicateKeyError as e:
    print ("The insert operation failed:", e)

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.

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.