Freigeben über

Verhindern von Ratenbegrenzungsfehlern bei Azure Cosmos DB for Apache Cassandra-Vorgängen

  • Artikel

GILT FÜR: Cassandra

Die Kosten sämtlicher Datenbankvorgänge werden von Azure Cosmos DB normalisiert und als Anforderungseinheiten (Request Units, RUs) ausgedrückt. Anforderungseinheiten stellen praktisch die „Währung“ zur Abstrahierung von Systemressourcen wie CPU, IOPS und Arbeitsspeicher dar, die zum Ausführen der von Azure Cosmos DB unterstützten Datenbankvorgänge erforderlich sind.

Bei Azure Cosmos DB for Apache Cassandra-Vorgängen treten möglicherweise Ratenbegrenzungsfehler (OverloadedException/429) auf, wenn sie den Durchsatzgrenzwert (in RUs) einer Tabelle überschreiten. Dies kann clientseitig gehandhabt werden, wie es hier beschrieben. ist. Wenn die Wiederholungsrichtlinie des Clients nicht implementiert werden kann, um den Ratenbegrenzungsfehler zu behandeln, können Sie das SSR-Feature (Server-Side Retry, serverseitige Widerholung) verwenden. Hiermit werden Vorgänge, die das Durchsatzlimit einer Tabelle überschreiten, nach einer kurzen Verzögerung automatisch wiederholt. Dies ist eine Einstellung auf Kontoebene und gilt für alle Schlüsselräume und Tabellen im Konto.

Verwenden des Azure-Portals

  1. Melden Sie sich beim Azure-Portal an.

  2. Navigieren Sie zu Ihrem Azure Cosmos DB for Apache Cassandra-Konto.

  3. Wechseln Sie im Abschnitt Einstellungen zum Bereich Features.

  4. Wählen Sie Serverseitige Wiederholung aus.

  5. Klicken Sie auf Aktivieren, um dieses Feature für alle Sammlungen in Ihrem Konto zu aktivieren.

Screenshot des Features zur serverseitigen Wiederholung für Azure Cosmos DB for Apache Cassandra

Verwenden der Azure-CLI

  1. Überprüfen Sie, ob SSR für Ihr Konto bereits aktiviert ist:

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

  2. Aktivieren Sie SSR für alle Tabellen in Ihrem Datenbankkonto. Es kann bis zu 15 Minuten dauern, bis diese Änderung wirksam wird.

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

  3. Mit dem folgenden Befehl wird die serverseitige Wiederholung für alle Tabellen in Ihrem Datenbankkonto deaktiviert, indem DisableRateLimitingResponses aus der Liste der Funktionen entfernt wird. Es kann bis zu 15 Minuten dauern, bis diese Änderung wirksam wird.

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

Häufig gestellte Fragen

Wie werden Anforderungen wiederholt?

Anforderungen werden fortlaufend (also immer wieder) wiederholt, bis ein 60-Sekunden-Timeout erreicht wird. Wenn das Timeout erreicht ist, erhält der Client entsprechend einen Timeoutfehler für den Lese- oder Schreibvorgang.

Wann ist SSR am nützlichsten?

Die serverseitige Wiederholung (Server-Side Retry, SSR) ist besonders nützlich, wenn eine plötzliche Spitze über einen kurzen Zeitraum von weniger als einer Minute auftritt, bei der Drosselungsfehler vermieden werden können. Wenn die Arbeitsauslastung zugenommen hat und konstant oberhalb des angegebenen RU-Werts liegt, wird SSR nicht viel nützen. Hier wird vorgeschlagen, die Anzahl der RUs entsprechend zu erhöhen.

Welche clientseitigen Einstellungen werden empfohlen?

Nachdem SSR aktiviert wurde, sollte die Client-App das Lesetimeout auf einen höheren Wert als die Wiederholungseinstellung des Servers von 60 Sekunden festlegen. Um auf der sichereren Seite zu sein, werden 90 Sekunden empfohlen.

Codebeispiel für Treiber 3

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

Codebeispiel für Treiber 4

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

Wie kann ich die Auswirkungen einer serverseitigen Wiederholung überwachen?

Sie können im Azure Cosmos DB-Bereich „Metriken“ die serverseitig wiederholten Ratenbegrenzungsfehler (429) einsehen. Diese Fehler werden nicht an den Client gesendet, wenn SSR aktiviert ist, da sie serverseitig behandelt und wiederholt werden.

Sie können in Ihren Azure Cosmos DB-Ressourcenprotokollen nach Protokolleinträgen suchen, die estimatedDelayFromRateLimitingInMilliseconds enthalten.

Wirkt sich die serverseitige Wiederholung auf meine Konsistenzebene aus?

Die serverseitige Wiederholung hat keine Auswirkung auf Konsistenzebenen. Anforderungen werden serverseitig wiederholt, wenn bei ihnen eine Ratenbegrenzung vorliegt (Fehler 429).

Hat die serverseitige Wiederholung Auswirkungen auf Fehlertypen, die ggf. von meinem Client empfangen werden?

Nein, die serverseitige Wiederholung hat nur Auswirkungen auf Ratenbegrenzungsfehler (429), indem diese serverseitig wiederholt werden. Dieses Feature sorgt dafür, dass Ratenbegrenzungsfehler nicht in der Clientanwendung behandelt werden müssen. Alle anderen Fehler werden an den Client gesendet.

Nächste Schritte

Weitere Informationen zur Problembehandlung bei häufigen Fehlern finden Sie in diesem Artikel:

Informationen zur Durchsatzbereitstellung in Azure Cosmos DB finden Sie in den folgenden Artikeln: