Az Apache Cassandra-műveletekhez készült Azure Cosmos DB sebességkorlátozó hibáinak megelőzése

  • Cikk

A KÖVETKEZŐKRE VONATKOZIK: Cassandra

Az adatbázis-műveletek költségeit az Azure Cosmos DB normalizálja, és a kérelemegységek (RU) fejezik ki. A kérelemegység az Azure Cosmos DB által támogatott adatbázis-műveletek végrehajtásához szükséges rendszererőforrások, például a CPU, az IOPS és a memória kivonatolása.

Az Apache Cassandra-hez készült Azure Cosmos DB-műveletek sebességkorlátozással (OverloadedException/429) meghiúsulhatnak, ha túllépik egy tábla átviteli sebességkorlátját (RU-kat). Ezt ügyféloldali módon lehet kezelni az itt leírtak szerint. Ha az ügyfél újrapróbálkozási szabályzata nem valósítható meg a sebességkorlátozási hiba miatti hiba kezeléséhez, akkor a kiszolgálóoldali újrapróbálkozási (SSR) funkciót is használhatjuk, ahol a tábla átviteli sebességkorlátját túllépő műveleteket a rendszer rövid késleltetés után automatikusan újrapróbálja. Ez egy fiókszintű beállítás, amely a fiók összes kulcsterére és táblájára érvényes.

Az Azure Portal használata

  1. Jelentkezzen be az Azure Portal.

  2. Lépjen az Apache Cassandra-hoz készült Azure Cosmos DB-fiókra.

  3. Nyissa meg a Szolgáltatások panelt a Beállítások szakasz alatt.

  4. Válassza a Kiszolgálóoldali újrapróbálkozás lehetőséget.

  5. Kattintson az Engedélyezés gombra a funkció engedélyezéséhez a fiók összes gyűjteményéhez.

Képernyőkép az Apache Cassandra-hoz készült Azure Cosmos DB kiszolgálóoldali újrapróbálkozása funkcióról

Az Azure parancssori felületének használata

  1. Ellenőrizze, hogy az SSR már engedélyezve van-e a fiókjához:

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

  2. Engedélyezi SSR az adatbázisfiók összes táblájához. A módosítás érvénybe lépése akár 15 percet is igénybe vehet.

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

  3. A következő parancs letiltja az adatbázisfiók összes táblájának kiszolgálóoldali újrapróbálkozását a képességlista eltávolításával DisableRateLimitingResponses . A módosítás érvénybe lépése akár 15 percet is igénybe vehet.

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

Gyakori kérdések

Hogyan próbálkoznak újra a kérések?

A kérelmeket a rendszer folyamatosan (újra és újra) újrapróbálja, amíg el nem éri a 60 másodperces időtúllépést. Ha eléri az időtúllépést, az ügyfél ennek megfelelően olvasási vagy írási időtúllépési hibát kap

Mikor előnyös az SSR?

A kiszolgálóoldali újrapróbálkozás (SSR) akkor a legkedvezőbb, ha hirtelen megugrik egy 1 percnél rövidebb ideig, amikor a szabályozási hibák elkerülhetők. Ha a munkaterhelés megnőtt, és folyamatosan a megadott ru felett maradna, akkor az SSR nem sokat segít. A javaslat a kérelemegység megfelelő növelése.

Javasolt ügyféloldali beállítások?

Az SSR engedélyezése után az ügyfélalkalmazásnak növelnie kell az olvasási időtúllépést a kiszolgáló 60 másodperces újrapróbálkozása után. Azt javasoljuk, hogy 90 másodpercig legyen a biztonságosabb oldalon.

Kódminta illesztőprogram3

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

Kódmintaillesztő4

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

Hogyan monitorozhatom a kiszolgálóoldali újrapróbálkozás hatásait?

Az Azure Cosmos DB-metrikák panelen megtekintheti a kiszolgálóoldalon újrapróbálkozott sebességkorlátozó hibákat (429). Ezek a hibák nem kerülnek az ügyfélhez, ha az SSR engedélyezve van, mivel a rendszer kezeli és újrapróbálja őket a kiszolgálóoldalon.

Az Azure Cosmos DB-erőforrásnaplókban megkeresheti a estimatedDelayFromRateLimitingInMilliseconds nevű naplóbejegyzéseket.

Hatással lesz a kiszolgálóoldali újrapróbálkozás a konzisztenciaszintemre?

A kiszolgálóoldali újrapróbálkozás nem befolyásolja a konzisztenciaszinteket. A kérések kiszolgálóoldali újrapróbálkozása, ha korlátozottak a sebességük (429-s hiba).

A kiszolgálóoldali újrapróbálkozás hatással van az ügyfél által esetlegesen kapott hibákra?

Nem, a kiszolgálóoldali újrapróbálkozások csak a sebességkorlátozó hibákat (429) érintik a kiszolgálóoldali újrapróbálkozással. Ez a funkció megakadályozza, hogy kezelnie kell a sebességkorlátozó hibákat az ügyfélalkalmazásban. Az összes többi hiba az ügyfélhez kerül.

Következő lépések

A gyakori hibák elhárításával kapcsolatos további információkért tekintse meg ezt a cikket:

Az átviteli sebesség Azure Cosmos DB-ben történő kiépítéséről az alábbi cikkekben olvashat: