Delen via

Snelheidsbeperkingsfouten voorkomen voor Azure Cosmos DB voor Apache Cassandra-bewerkingen

  • Artikel

VAN TOEPASSING OP: Cassandra

De kosten van alle databasebewerkingen worden genormaliseerd door Azure Cosmos DB en worden uitgedrukt in aanvraageenheden (RU). Aanvraageenheid is een prestatievaluta die de systeemresources, zoals CPU, IOPS en geheugen, abstraheert die nodig zijn om de databasebewerkingen uit te voeren die worden ondersteund door Azure Cosmos DB.

Azure Cosmos DB voor Apache Cassandra-bewerkingen kunnen mislukken met snelheidsbeperkingsfouten (OverloadedException/429) als ze de doorvoerlimiet (RU's) van een tabel overschrijden. Dit kan worden verwerkt door de client, zoals hier wordt beschreven. Als het beleid voor opnieuw proberen van de client niet kan worden geïmplementeerd om de fout te verwerken vanwege een fout met snelheidsbeperking, kunnen we de functie Voor opnieuw proberen (SSR) aan de serverzijde gebruiken waarbij bewerkingen die de doorvoerlimiet van een tabel overschrijden, automatisch opnieuw worden geprobeerd na een korte vertraging. Dit is een instelling op accountniveau en is van toepassing op alle sleutelruimten en tabellen in het account.

De Azure-portal gebruiken

  1. Meld u aan bij het Azure-portaal.

  2. Navigeer naar uw Azure Cosmos DB voor Apache Cassandra-account.

  3. Ga naar het deelvenster Functies onder de sectie Instellingen .

  4. Selecteer Opnieuw proberen aan serverzijde.

  5. Klik op Inschakelen om deze functie in te schakelen voor alle verzamelingen in uw account.

Schermopname van de functie voor opnieuw proberen aan de serverzijde voor Azure Cosmos DB voor Apache Cassandra

De Azure CLI gebruiken

  1. Controleer of SSR al is ingeschakeld voor uw account:

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

  2. Schakel SSR in voor alle tabellen in uw databaseaccount. Het kan tot 15 minuten duren voordat deze wijziging van kracht wordt.

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

  3. Met de volgende opdracht wordt het opnieuw proberen aan de serverzijde uitgeschakeld voor alle tabellen in uw databaseaccount door deze uit de lijst met mogelijkheden te verwijderen DisableRateLimitingResponses . Het kan tot 15 minuten duren voordat deze wijziging van kracht wordt.

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

Veelgestelde vragen

Hoe worden aanvragen opnieuw geprobeerd?

Aanvragen worden continu (telkens opnieuw) geprobeerd totdat een time-out van 60 seconden is bereikt. Als de time-out is bereikt, ontvangt de client een time-outfout voor lezen of schrijven dienovereenkomstig

Wanneer is SSR het nuttigst?

Opnieuw proberen aan de serverzijde (SSR) is het nuttigst wanneer er een plotselinge piek is voor een korte duur van minder dan 1 minuut, waarbij beperkingsfouten kunnen worden vermeden. Als de werkbelasting is toegenomen en constant boven de opgegeven RU blijft, zal SSR niet veel helpen. De suggestie is om de RU op de juiste manier te verhogen.

Voorgestelde instellingen aan de clientzijde?

Nadat SSR is ingeschakeld, moet de client-app de leestime-out verhogen buiten de instelling voor opnieuw proberen van 60 seconden op de server. We raden 90 seconden aan om aan de veiligere kant te zijn.

Codevoorbeeldstuurprogramma3

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

Codevoorbeeldstuurprogramma4

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

Hoe kan ik de effecten van een nieuwe poging aan de serverzijde controleren?

U kunt de snelheidsbeperkingsfouten (429) bekijken die opnieuw aan de serverzijde worden geprobeerd in het deelvenster Metrische gegevens van Azure Cosmos DB. Deze fouten gaan niet naar de client wanneer SSR is ingeschakeld, omdat ze worden verwerkt en opnieuw worden geprobeerd aan de serverzijde.

U kunt zoeken naar logboekvermeldingen met estimatedDelayFromRateLimitingInMilliseconds in uw Azure Cosmos DB-resourcelogboeken.

Is het opnieuw proberen aan de serverzijde van invloed op mijn consistentieniveau?

Opnieuw proberen aan de serverzijde heeft geen invloed op consistentieniveaus. Aanvragen worden opnieuw geprobeerd aan de serverzijde als ze beperkt zijn (fout 429).

Heeft een nieuwe poging aan de serverzijde invloed op elk type fout dat mijn client kan ontvangen?

Nee, nieuwe pogingen aan de serverzijde zijn alleen van invloed op frequentiebeperkingsfouten (429) door ze opnieuw te proberen aan de serverzijde. Met deze functie voorkomt u dat u fouten met snelheidsbeperking in de clienttoepassing moet afhandelen. Alle andere fouten gaan naar de client.

Volgende stappen

Zie dit artikel voor meer informatie over het oplossen van veelvoorkomende fouten:

Zie de volgende artikelen voor meer informatie over het inrichten van doorvoer in Azure Cosmos DB: