La sobrecarga se produce cuando su clúster recibe más operaciones entrantes de las que sus recursos pueden procesar, y puede provocar una interrupción del servicio total o casi total en su clúster. Load Shedding, una funcionalidad de Intelligent carga de trabajo gestión (IWM), permite a Atlas rechazar operaciones durante una sobrecarga prolongada. Para configurar Load Shedding para su clúster, consulte Configurar Intelligent carga de trabajo gestión.
Cuando Load Shedding rechaza una operación, su aplicación podría ver un nuevo error para esa operación con la etiqueta SystemOverloadedError. Este error indica que su clúster está sobrecargado y está descartando operaciones.
Si utiliza una librería de cliente consciente de la contrapresión, la librería de cliente reconoce estos errores y reintenta los que se pueden reintentar de forma segura. Su aplicación sigue controlando cuánto tiempo seguir reintentando y cuándo descargar la carga. Para aprender más, consulte Gestionar errores de sobrecarga.
La etiqueta SystemOverloadedError por sí sola no media que la operación se pueda reintentar de forma segura. Para determinar si un error de sobrecarga es reintentable, compruebe las siguientes etiquetas:
RetryableError- la operación no se ejecutó y es seguro reintentarloNoWritesPerformed- el servidor rechazó la operación antes de guardar
El siguiente ejemplo muestra un error de sobrecarga que Atlas devuelve cuando Load Shedding rechaza una operación:
{ "ok": 0.0, "errmsg": "Request rejected: ingress operation rate limit exceeded", "code": 463, "codeName": "IngressOperationRateLimitExceeded", "errorLabels": ["SystemOverloadedError", "RetryableError", "NoWritesPerformed"] }
Importante
Si un error de sobrecarga no incluye la etiqueta RetryableError, asegúrese de que la operación sea idempotente y espere antes de volver a intentarlo para evitar contribuir a la sobrecarga. Utilice retroceso exponencial y aleatorización en su lógica de reintento.
Versiones de Librerías de clientes con conocimiento de backpressure
Los drivers conscientes de contrapresión y otras bibliotecas cliente reconocen automáticamente los errores de sobrecarga con la etiqueta SystemOverloadedError y los tratan como una señal de sobrecarga. Si el error tiene una etiqueta que induce un reintento, incluida la etiqueta RetryableError, la biblioteca cliente con reconocimiento de contrapresión vuelve a intentar automáticamente la operación con retroceso exponencial y jitter.
La siguiente tabla enumera las versiones más antiguas de las Librerías de clientes que son compatibles con la comprensión de presión inversa:
Librerías de clientes | Primera versión con reconocimiento de Backpressure |
|---|---|
Controlador de C | 2.5 |
Controlador C++ | 4.6 |
Controlador .NET/C# | 3.11 |
Driver de Go | 2.9 |
Java Sync Driver | 5.12 |
Driver de Java Reactive Streams | 5.12 |
driver de Kotlin corrutina | 5.12 |
Driver de sincronización de Kotlin | 5.12 |
Driver de Nodo.js | 7.6 |
Biblioteca PHP | 2.5; requiere |
PyMongo | 4.18 |
Controlador de Scala | 5.12 |
Ruby | 2.26 |
Rust | 3.9 |
Gestionar errores de sobrecarga
Gestionar errores de sobrecarga en su aplicación incluso si utiliza una librería de cliente con reconocimiento de contrapresión. Las librerías de clientes conscientes de la contrapresión reintentan las operaciones etiquetadas como reintentables, pero su aplicación decide durante cuánto tiempo seguir reintentando y cuándo descargar la carga abandonando las operaciones que el clúster sigue rechazando. Si no está utilizando una librería de cliente con reconocimiento de contrapresión, implemente también la lógica de detección de errores y reintentos usted mismo.
Consulte el siguiente procedimiento para ver ejemplos de cómo implementar la lógica de detección de errores y reintentos con retroceso exponencial para gestionar errores de sobrecarga que están etiquetados como reintentables:
Utilice el siguiente procedimiento para implementar utilidades que detecten errores por sobrecarga y reintenten con retroceso exponencial.
Directrices para reintentos seguros de sobrecarga
Al reintentar operaciones que fallaron debido a un error de sobrecarga, utilice las siguientes directrices para evitar contribuir a la sobrecarga y aumentar las posibilidades de reintentos exitosos:
Limite sus reintentos: Utilice un máximo de dos reintentos por operación. Unos límites más altos reducen los errores, pero aumentan la carga del servidor durante la sobrecarga, mientras que menos reintentos pueden reducir la carga del servidor, pero aumentan los errores.
Aplica selectivamente: Utiliza este patrón solo para operaciones sensibles a la latencia o críticas para el negocio. Para cargas de trabajo en segundo plano, registrar errores y reintentar a un nivel superior con retrasos más prolongados.