A sobrecarga ocorre quando o cluster recebe mais operações de entrada do que seus recursos podem processar e pode causar uma interrupção total ou quase total no cluster. O descarte de carga, um recurso do Intelligent Workload Management (IWM), permite que o Atlas rejeite operações durante a sobrecarga prolongado. Para configurar o descarte de carga para seu cluster, consulte Configurar o Intelligent Workload Management.
Quando a redução de carga rejeita uma operação, seu aplicação 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.
Se você usar uma biblioteca de cliente com reconhecimento de backpressure, a biblioteca de cliente reconhecerá esses erros e tentará novamente os que são seguros para tentar novamente. Seu aplicação ainda controla por quanto tempo tentar novamente e quando reduzir a carga. Para saber mais, consulte Identificar errosde sobrecarga.
O rótulo SystemOverloadedError em si não média que a operação pode ser repetida com segurança. Para determinar se um erro de sobrecarga pode ser repetido, verifique as seguintes etiquetas:
RetryableError- a operação não foi executada e é seguro tentar novamenteNoWritesPerformed- o servidor rejeitou a operação antes de realizar qualquer escrita
O exemplo a seguir mostra um erro de sobrecarga que o Atlas retorna quando o descarte de carga 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 e jitter exponenciais em sua lógica de repetição.
Versões de bibliotecas de clientes com reconhecimento de backpressure
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 |
PyMongo | 4.18 |
Driver Scala | 5.12 |
Ruby | 2.26 |
Rust | 3.9 |
Gerenciar erros de sobrecarga
Lide com erros de sobrecarga em seu aplicação , mesmo se você usar uma biblioteca de cliente com reconhecimento de backpressure. As bibliotecas de cliente com reconhecimento de backpressure repetem operações rotuladas como repetíveis, mas seu aplicação decide por quanto tempo continuar tentando e quando reduzir a carga abandonando as operações que o cluster continua rejeitando. Se você não estiver usando uma biblioteca de cliente com reconhecimento de backpressure, implemente também a lógica de detecção de erros e tente você mesmo.
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 rotulados como repetíveis:
Use o procedimento a seguir para implementar utilitários para detectar erros de sobrecarga e tentar novamente com backoff exponencial.
Diretriz para novas tentativas de sobrecarga seguras
Ao tentar novamente operações que falharam devido a um erro de sobrecarga, use as seguintes diretrizes para evitar contribuir para a sobrecarga e para aumentar as chances de novas tentativas bem-sucedidas:
Limite suas tentativas de repetição: use um máximo de duas tentativas 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 erros.
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.