Megosztás a következőn keresztül:

Az Apache Cassandra-műveletekhez készült Azure Cosmos DB sebességkorlátozó hibáinak megakadályozása

  • 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 olyan teljesítmény-pénznem, amely az Azure Cosmos DB által támogatott adatbázis-műveletek végrehajtásához szükséges rendszererőforrásokat, például a CPU-t, az IOPS-t és a memóriát absztrakciós pénznemként használja.

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

Az Azure Portal használata

  1. Jelentkezzen be az Azure Portalra.

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

  3. Lépjen a Szolgáltatások panelre 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ásának 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élyezze az SSR-t 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. Az alábbi 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ávalDisableRateLimitingResponses. 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álkozza, 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 fog kapni

Mikor a legkedvezőbb az SSR?

A kiszolgálóoldali újrapróbálkozások (SSR) akkor a legkedvezőbbek, ha egy rövid, 1 percnél rövidebb ideig tartó hirtelen kiugrás történik, ahol a szabályozási hibák elkerülhetők. Ha a munkaterhelés növekedett, és folyamatosan a megadott ru felett maradna, akkor az SSR nem sokat segít. A javaslat a ru 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ásodperc legyen a biztonságosabb oldalon.

Kódminta-illesztőprogram3

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

Kódminta-illesztőprogram4

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

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

Az Azure Cosmos DB Metrics 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álkozza a kiszolgálóoldalt.

Az Azure Cosmos DB-erőforrásnaplókban kereshet a estimatedDelayFromRateLimitingInMilliseconds-t tartalmazó naplóbejegyzéseket.

A kiszolgálóoldali újrapróbálkozás hatással lesz 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ásra kerülnek, ha korlátozott a sebességük (429-s hiba).

A kiszolgálóoldali újrapróbálkozás hatással van az ügyfelem által esetleg kapott bármilyen típusú hibára?

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 Azure Cosmos DB átviteli sebességének kiépítéséről az alábbi cikkekben olvashat: