Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.
Menu Docs

Lidar com erros de sobrecarga causados pelo load shedding

A sobrecarga ocorre quando seu cluster recebe mais operações de entrada do que seus recursos podem processar, e pode causar uma interrupção total ou quase total no seu cluster. Load Shedding, um recurso de Gerenciamento Inteligente de Carga de Trabalho (IWM), permite que o Atlas rejeite operações durante sobrecarga prolongada. Para configurar o descarte de carga para seu cluster, consulte Configurar o gerenciamento inteligente de carga de trabalho.

Quando o Load Shedding rejeita uma operação, seu aplicativo pode ver um novo erro para essa operação com o rótulo SystemOverloadedError. Esse erro indica que seu cluster está sobrecarregado e descartando operações.

If you use a backpressure-aware client library, the client library recognizes these errors and retries the ones that are safe to retry. Your application still controls how long to keep retrying and when to shed load. To learn more, see Handle Overload Errors.

O rótulo SystemOverloadedError por si só não significa que a operação pode ser repetida com segurança. Para determinar se um erro de sobrecarga é repetível, verifique os seguintes rótulos:

  • RetryableError - a operação não foi executada e é seguro tentar novamente

  • NoWritesPerformed - o servidor rejeitou a operação antes de realizar qualquer gravar

O exemplo a seguir mostra um erro de sobrecarga que o Atlas retorna quando o Load Shedding rejeita uma operação:

{
"ok": 0.0,
"errmsg": "Request rejected: ingress operation rate limit exceeded",
"code": 463,
"codeName": "IngressOperationRateLimitExceeded",
"errorLabels": ["SystemOverloadedError", "RetryableError", "NoWritesPerformed"]
}

Importante

Se um erro de sobrecarga não incluir o rótulo RetryableError, certifique-se de que a operação seja idempotente e aguarde antes de tentar novamente para evitar contribuir para a sobrecarga. Use backoff exponencial e jitter na sua lógica de repetição.

Drivers com reconhecimento de backpressure e outras bibliotecas de cliente reconhecem automaticamente erros de sobrecarga com o rótulo SystemOverloadedError e os tratam como um sinal de sobrecarga. Se o erro tiver um rótulo que induz a uma nova tentativa, incluindo o rótulo RetryableError, a biblioteca do cliente com reconhecimento de backpressure tentará automaticamente a operação com backoff e jitter exponenciais.

A tabela a seguir lista as primeiras versões da biblioteca do cliente que reconhecem a backpressure:

Biblioteca do cliente
Versão mais antiga com reconhecimento de backpressure

Driver C

2.5

Driver C++

4.6

Driver .NET/C#

3.11

Driver GO

2.9

Driver de sincronização Java

5.12

Driver de fluxos reativos do Java

5.12

Driver Kotlin Coroutine

5.12

Driver de Kotlin Sync

5.12

Controlador Node.js

7.6

Biblioteca PHP

2.5; requer a extensão mongodb do PHP (PHPC) 2.5.0+

PyMongo

4.18

Driver Scala

5.12

Ruby

2.26

Rust

3.9

Handle overload errors in your application even if you use a backpressure-aware client library. Backpressure-aware client libraries retry operations labeled as retryable, but your application decides how long to keep retrying and when to shed load by abandoning operations that the cluster continues to reject. If you are not using a backpressure-aware client library, also implement the error detection and retry logic yourself.

Consulte o procedimento a seguir para obter exemplos de como implementar a detecção de erros e a lógica de repetição com backoff exponencial para lidar com erros de sobrecarga que são marcados como repetíveis:

Use o procedimento a seguir para implementar utilitários para detectar erros de sobrecarga e tentar novamente com backoff exponencial.

Ao repetir operações que falharam devido a um erro de sobrecarga, use as seguintes diretrizes para evitar contribuir para a sobrecarga e aumentar as chances de tentativas bem-sucedidas:

  • Limite suas tentativas de repetição: use no máximo duas repetições por operação. Limites mais altos reduzem as taxas de erro, mas aumentam a carga do servidor durante a sobrecarga, enquanto menos tentativas de repetição podem reduzir a carga do servidor, mas aumentar as taxas de erro.

  • Aplicar seletivamente: use esse padrão somente para operações sensíveis à latência ou críticas aos negócios. Para cargas de trabalho em segundo plano, registre os erros e tente novamente em um nível superior com atrasos mais longos.