Aracılığıyla paylaş


Apache Cassandra işlemleri için Azure Cosmos DB'de hız sınırlama hatalarını önleme

ŞUNLAR IÇIN GEÇERLIDIR: Cassandra

Tüm veritabanı işlemlerinin maliyeti Azure Cosmos DB tarafından normalleştirilir ve İstek Birimleri (RU) ile ifade edilir. İstek birimi, Azure Cosmos DB tarafından desteklenen veritabanı işlemlerini gerçekleştirmek için gereken CPU, IOPS ve bellek gibi sistem kaynaklarını soyutlayan bir performans para birimidir.

Apache Cassandra için Azure Cosmos DB işlemleri, tablonun aktarım hızı sınırını (RU) aşarsa hız sınırlama (OverloadedException/429) hatalarıyla başarısız olabilir. Bu, burada açıklandığı gibi istemci tarafından işlenebilir. İstemci yeniden deneme ilkesi hız sınırlama hatası nedeniyle hatayı işlemek için uygulanamazsa, tablonun aktarım hızı sınırını aşan işlemlerin kısa bir gecikmeden sonra otomatik olarak yeniden deneneceği Sunucu tarafı yeniden deneme (SSR) özelliğini kullanabiliriz. Bu bir hesap düzeyi ayarıdır ve hesaptaki tüm Anahtar alanları ve Tablolar için geçerlidir.

Azure portal’ı kullanma

  1. Azure Portal’ında oturum açın.

  2. Apache Cassandra için Azure Cosmos DB hesabınıza gidin.

  3. Ayarlar bölümünün altındaki Özellikler bölmesine gidin.

  4. Sunucu Tarafı Yeniden Dene'yi seçin.

  5. Hesabınızdaki tüm koleksiyonlarda bu özelliği etkinleştirmek için Etkinleştir'e tıklayın.

Apache Cassandra için Azure Cosmos DB'ye yönelik sunucu tarafı yeniden deneme özelliğinin ekran görüntüsü

Azure CLI'yi kullanma

  1. Hesabınız için SSR'nin zaten etkin olup olmadığını denetleyin:

    az cosmosdb show --name accountname --resource-group resourcegroupname
    
  2. Veritabanı hesabınızdaki tüm tablolar için SSR'yi etkinleştirin . Bu değişikliğin geçerli olması 15 dakika kadar sürebilir.

    az cosmosdb update --name accountname --resource-group resourcegroupname --capabilities EnableCassandra DisableRateLimitingResponses
    
  3. Aşağıdaki komut, yetenek listesinden kaldırarak DisableRateLimitingResponses veritabanı hesabınızdaki tüm tablolar için sunucu tarafı yeniden denemesini devre dışı bırakır. Bu değişikliğin geçerli olması 15 dakika kadar sürebilir.

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

Sık sorulan sorular

İstekler nasıl yeniden deneniyor?

İstekler, 60 saniyelik zaman aşımına ulaşılana kadar sürekli (tekrar tekrar) yeniden deneniyor. Zaman aşımına ulaşılırsa istemci buna göre okuma veya yazma zaman aşımı hatası alır

SSR ne zaman en yararlı olur?

Sunucu tarafı yeniden denemesi (SSR), azaltma hatalarının önlenebileceği 1 dakikadan kısa bir süre boyunca ani bir ani artış olduğunda en faydalıdır. İş yükü artmışsa ve sürekli olarak belirtilen RU'nun üzerinde kalacaksa, SSR çok yardımcı olmayacaktır. Öneri, RU'ları uygun şekilde artırmaktır.

Önerilen istemci tarafı ayarları?

SSR etkinleştirildikten sonra istemci uygulaması, sunucu yeniden deneme 60 saniye ayarının ötesinde okuma zaman aşımını artırmalıdır. Güvenli tarafta olmak için 90 saniyenizi öneririz.

Kod Örneği Sürücüsü3

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

Kod Örneği Sürücüsü4

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

Sunucu tarafı yeniden denemesinin etkilerini nasıl izleyebilirim?

Sunucu tarafında yeniden denenen hız sınırlama hatalarını (429) Azure Cosmos DB Ölçümleri bölmesinde görüntüleyebilirsiniz. Bu hatalar SSR etkinleştirildiğinde istemciye gitmez, çünkü bunlar sunucu tarafında işlenir ve yeniden denener.

Azure Cosmos DB kaynak günlüklerinizde tahminiDelayFromRateLimitingInMilliseconds içeren günlük girdilerini arayabilirsiniz.

Sunucu tarafı yeniden denemesi tutarlılık düzeyimi etkileyecek mi?

Sunucu tarafı yeniden denemesi tutarlılık düzeylerini etkilemez. İstekler hız sınırlıysa sunucu tarafında yeniden denenir (Hata 429).

Sunucu tarafı yeniden denemesi istemcimin alabileceği herhangi bir hata türünü etkiler mi?

Hayır, sunucu tarafı yeniden denemesi yalnızca sunucu tarafında yeniden denenerek hız sınırlama hatalarını (429) etkiler. Bu özellik, istemci uygulamasında hız sınırlama hatalarını işlemeniz gerekmesini önler. Diğer tüm hatalar istemciye gider.

Sonraki adımlar

Yaygın hataları giderme hakkında daha fazla bilgi edinmek için şu makaleye bakın:

Azure Cosmos DB'de aktarım hızı sağlama hakkında bilgi edinmek için aşağıdaki makalelere bakın: