Share via

Empêcher des erreurs de limitation de débit pour les opérations d’Azure Cosmos DB for Apache Cassandra

  • Article

S’APPLIQUE À : Cassandra

Le coût de toutes les opérations de base de données, normalisé par Azure Cosmos DB, est exprimé en unités de requête (RU). Les unités de requête correspondent en quelque sorte à une devise de performances, faisant abstraction des ressources système (UC, IOPS, mémoire, etc.) requises pour effectuer les opérations de base de données prises en charge par Azure Cosmos DB.

Les opérations d’Azure Cosmos DB for Apache Cassandra peuvent échouer avec des erreurs de limitation de débit (OverloadedException/429) si elles dépassent la limite de débit d’une table (RU). Cette situation peut être gérée côté client, comme décrit ici. Si la stratégie de nouvelles tentatives du client ne peut pas être implémentée pour gérer l’échec dû à une erreur de limitation de débit, nous pouvons utiliser la fonctionnalité de nouvelles tentatives côté serveur (SSR) où les opérations qui dépassent la limite de débit d’une table seront automatiquement relancées après un court délai. Il s’agit d’un paramètre au niveau du compte qui s’applique à tous les espaces clés et à toutes les tables du compte.

Utilisation du portail Azure

  1. Connectez-vous au portail Azure.

  2. Accédez à votre compte Azure Cosmos DB for Apache Cassandra.

  3. Accédez au volet Fonctionnalités dans la section Paramètres.

  4. Sélectionnez Nouvelle tentative côté serveur.

  5. Cliquez sur Activer pour activer cette fonctionnalité pour tous les collections dans votre compte.

Capture d’écran de la fonctionnalité de nouvelles tentatives côté serveur pour Azure Cosmos DB for Apache Cassandra

Utilisation de l’interface de ligne de commande Microsoft Azure

  1. Vérifiez si la fonctionnalité SSR est déjà activée pour votre compte :

    az cosmosdb show --name accountname --resource-group resourcegroupname

  2. Activez la fonctionnalité SSR pour toutes les tables dans votre compte de base de données. Jusqu’à quinze minutes peuvent être nécessaires pour que cette modification soit prise en compte.

    az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableCassandra DisableRateLimitingResponses

  3. La commande suivante désactive la nouvelle tentative côté serveur pour toutes les tables dans votre compte de base de données en supprimant DisableRateLimitingResponses de la liste des capacités. Jusqu’à quinze minutes peuvent être nécessaires pour que cette modification soit prise en compte.

    az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableCassandra

Forum aux questions

Comment les demandes font-elles l’objet d’une nouvelle tentative ?

Les demandes font l’objet d’une nouvelle tentative en continu (de façon répétée) jusqu’à ce qu’un délai de 60 secondes soit atteint. Si le délai d’expiration est atteint, le client reçoit une erreur d’expiration du délai de lecture ou d’écriture en conséquence.

Quand la fonctionnalité SSR est-elle le plus avantageuse ?

La fonctionnalité de nouvelles tentatives côté serveur (SSR) est la plus avantageuse en cas de pic soudain pendant une courte durée de moins d’une minute, ce qui permet d’éviter les erreurs de limitation. Si la charge de travail a augmenté et reste constamment au-dessus de la RU spécifiée, la fonctionnalité SSR ne sera pas d’un grand secours. Il est suggéré d’augmenter la RU de manière appropriée.

Quels sont les paramètres suggérés côté client ?

Une fois la fonctionnalité SSR activée, l’application cliente doit augmenter le délai d’expiration de lecture au-delà des 60 secondes du paramètre des nouvelles tentatives du serveur. Nous vous recommandons 90 secondes pour plus de sécurité.

Exemple de code de pilote3

SocketOptions socketOptions = new SocketOptions()
	.setReadTimeoutMillis(90000);

Exemple de code de pilote4

ProgrammaticDriverConfigLoaderBuilder configBuilder = DriverConfigLoader.programmaticBuilder()
	.withDuration(DefaultDriverOption.REQUEST_TIMEOUT, Duration.ofSeconds(90));

Comment puis-je superviser les effets d’une nouvelle tentative côté serveur ?

Vous pouvez afficher les erreurs de limitation de débit (429) qui font l’objet d’une nouvelle tentative côté serveur dans le volet Métriques d’Azure Cosmos DB. Ces erreurs ne sont pas dirigées vers le client quand la fonctionnalité SSR est activée, car elles sont gérées et font l’objet d’une nouvelle tentative côté serveur.

Vous pouvez rechercher les entrées de journal contenant estimatedDelayFromRateLimitingInMilliseconds dans vos journaux de ressources Azure Cosmos DB.

La nouvelle tentative côté serveur a-t-elle une incidence sur mon niveau de cohérence ?

La nouvelle tentative côté serveur n’a pas d’impact sur les niveaux de cohérence. Les demandes font l’objet d’une nouvelle tentative côté serveur si elles subissent une limitation de débit (Erreur 429).

La nouvelle tentative côté serveur affecte-t-elle tout type d’erreur que mon client peut recevoir ?

Non, la nouvelle tentative côté serveur affecte uniquement les erreurs de limitation de débit (429) en effectuant une nouvelle tentative côté serveur. Cette fonctionnalité vous évide d’avoir à gérer les erreurs de limitation de débit dans l’application cliente. Toutes les autres erreurs sont dirigées vers le client.

Étapes suivantes

Pour en savoir plus sur la résolution des erreurs courantes, consultez cet article :

Consultez les articles suivants pour en savoir plus sur le provisionnement du débit dans Azure Cosmos DB :