Prevent rate-limiting errors for Azure Cosmos DB for MongoDB operations
APPLIES TO: MongoDB
Azure Cosmos DB for MongoDB operations might encounter rate-limiting, resulting in 16500 errors in mongo request metrics, if they exceed a collection's throughput limit (RUs).
Enable Server Side Retry (SSR) to automate operation retries. SSR retries requests across all collections in your account with short delays. If a 60-second timeout is reached, a client receives an ExceededTimeLimit exception (50).
Use the Azure portal
Sign in to the Azure portal.
Navigate to your Azure Cosmos DB for MongoDB account.
Go to the Features pane underneath the Settings section.
Select Server Side Retry.
Click Enable to enable this feature for all collections in your account.
Use the Azure CLI
Check if SSR is already enabled for your account:
az cosmosdb show --name accountname --resource-group resourcegroupname
Enable SSR for all collections in your database account. It may take up to 15 min for this change to take effect.
az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableMongo DisableRateLimitingResponses
The following command will Disable server-side retry for all collections in your database account by removing
DisableRateLimitingResponses
from the capabilities list. It may take up to 15 min for this change to take effect.az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableMongo
Frequently asked questions
How can I monitor the effects of a server-side retry?
You can search for log entries containing estimatedDelayFromRateLimitingInMilliseconds in your Azure Cosmos DB resource logs.
Will server-side retry affect my consistency level?
server-side retry does not affect a request's consistency. Requests are retried server-side if they are rate limited.
Does server-side retry affect any type of error that my client might receive?
No, server-side retry only affects rate limiting errors by retrying them server-side. This feature prevents you from having to handle rate-limiting errors in the client application. All other errors will go to the client.
Next steps
To learn more about troubleshooting common errors, see this article:
Trying to do capacity planning for a migration to Azure Cosmos DB? You can use information about your existing database cluster for capacity planning.
- For learning how to redistribute throughput across partitions, refer Learn how to redistribute throughput across partitions
- If all you know is the number of vcores and servers in your existing database cluster, read about estimating request units using vCores or vCPUs
- If you know typical request rates for your current database workload, read about estimating request units using Azure Cosmos DB capacity planner