Förhindra hastighetsbegränsningsfel för Azure Cosmos DB för Apache Cassandra-åtgärder

  • Artikel

GÄLLER FÖR: Cassandra

Kostnaden för alla databasåtgärder normaliseras av Azure Cosmos DB och uttrycks av RU (Request Units). Begärandeenheten är en prestandavaluta som abstraherar systemresurser som CPU, IOPS och minne som krävs för att utföra databasåtgärder som stöds av Azure Cosmos DB.

Azure Cosmos DB för Apache Cassandra-åtgärder kan misslyckas med hastighetsbegränsningsfel (OverloadedException/429) om de överskrider en tabells dataflödesgräns (RU:er). Detta kan hanteras av klientsidan enligt beskrivningen här. Om klientens återförsöksprincip inte kan implementeras för att hantera felet på grund av ett hastighetsbegränsningsfel kan vi använda funktionen för återförsök på serversidan (SSR) där åtgärder som överskrider en tabells dataflödesgräns görs om automatiskt efter en kort fördröjning. Det här är en inställning på kontonivå och gäller för alla nyckelutrymmen och tabeller i kontot.

Använda Azure-portalen

  1. Logga in på Azure-portalen.

  2. Gå till ditt Azure Cosmos DB för Apache Cassandra-konto.

  3. Gå till fönstret Funktioner under avsnittet Inställningar .

  4. Välj Försök igen på serversidan.

  5. Klicka på Aktivera för att aktivera den här funktionen för alla samlingar i ditt konto.

Skärmbild av funktionen för återförsök på serversidan för Azure Cosmos DB för Apache Cassandra

Använda Azure CLI

  1. Kontrollera om SSR redan är aktiverat för ditt konto:

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

  2. Aktivera SSR för alla tabeller i ditt databaskonto. Det kan ta upp till 15 minuter innan ändringen börjar gälla.

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

  3. Följande kommando inaktiverar återförsök på serversidan för alla tabeller i databaskontot genom att ta bort DisableRateLimitingResponses från listan över funktioner. Det kan ta upp till 15 minuter innan ändringen börjar gälla.

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

Vanliga frågor och svar

Hur görs nya försök med begäranden?

Begäranden görs kontinuerligt (om och om igen) tills en tidsgräns på 60 sekunder nås. Om tidsgränsen nås får klienten ett timeout-fel för läsning eller skrivning i enlighet med detta

När är SSR mest fördelaktigt?

Återförsök på serversidan (SSR) är mest fördelaktigt när det finns en plötslig topp under en kort tid på mindre än 1 minut där begränsningsfel kan undvikas. Om arbetsbelastningen har ökat och ständigt skulle ligga över den angivna RU:en hjälper SSR inte mycket. Förslaget är att öka RU på lämpligt sätt.

Föreslagna inställningar på klientsidan?

När SSR har aktiverats bör klientappen öka tidsgränsen för läsning utöver inställningen för serverförsök på 60 sekunder. Vi rekommenderar 90 sekunder för att vara på den säkrare sidan.

Kodexempeldrivrutin3

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

Kodexempeldrivrutin4

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

Hur kan jag övervaka effekterna av ett nytt försök på serversidan?

Du kan visa hastighetsbegränsningsfelen (429) som görs om på serversidan i fönstret Mått för Azure Cosmos DB. De här felen går inte till klienten när SSR är aktiverat, eftersom de hanteras och görs om på serversidan.

Du kan söka efter loggposter som innehåller estimatedDelayFromRateLimitingInMilliseconds i dina Azure Cosmos DB-resursloggar.

Kommer återförsök på serversidan att påverka min konsekvensnivå?

Återförsök på serversidan påverkar inte konsekvensnivåerna. Begäranden görs på serversidan igen om de är begränsade (fel 429).

Påverkar återförsök på serversidan någon typ av fel som min klient kan få?

Nej, återförsök på serversidan påverkar bara hastighetsbegränsningsfel (429) genom att försöka igen på serversidan. Den här funktionen förhindrar att du behöver hantera hastighetsbegränsningsfel i klientprogrammet. Alla andra fel går till klienten.

Nästa steg

Mer information om felsökning av vanliga fel finns i den här artikeln:

I följande artiklar kan du lära dig hur du etablerar dataflöde i Azure Cosmos DB: