Dela via

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

  • Artikel

GÄLLER FÖR: Kassandra

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 de 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 hastighetsbegränsningsfel kan vi använda funktionen för återförsök på serversidan 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 kontonivåinställning och gäller för alla nyckelutrymmen och tabeller i kontot.

Använda Azure Portal

  1. Logga in på Azure-portalen.

  2. Navigera till ditt Azure Cosmos DB för Apache Cassandra-kontot.

  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 ditt databaskonto 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 begäranden på nytt?

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 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 du kan undvika begränsningsfel. Om arbetsbelastningen har ökat och ständigt skulle ligga över den angivna RU:en hjälper inte SSR mycket. Förslaget är att öka RU:et 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 60-sekundersinställningen för servern igen. 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änsningsfel (429) som görs om på serversidan i fönstret Mått för Azure Cosmos DB. Dessa fel 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å nytt på serversidan om de är hastighetsbegränsade (fel 429).

Påverkar omförsök på serversidan någon typ av fel som min klient kan ta emot?

Nej, omförsök på serversidan påverkar endast hastighetsbegränsningsfel (429) genom att försöka igen på serversidan. Den här funktionen hindrar dig från att behöva hantera hastighetsbegränsningsfel i klientprogrammet. Alla andra fel går till klienten.

Nästa steg

Mer information om hur du felsöker 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: