ReplicatedWriteConflictException

TL;DR — Başka bir Bölgedeki bir istek aynı öğeyi değiştirirken bir çok Bölgeli güçlü tutarlı (MRSC) global tablodaki bir öğeye yazdınız. Güçlü çok Bölgeli tutarlılık her iki kazananın da inmesine izin veremez, bu yüzden bir yazma reddedilir. AWS onu yeniden denenebilir olarak belgeler: geri çekilin ve yeniden deneyin ve yapabildiğiniz yerde sıcak öğelerdeki Bölgeler arası çekişmeyi azaltın.

Ne anlama gelir

ReplicatedWriteConflictException: One or more items in this request are
being modified by a request in another Region.

Klasik (nihai tutarlı) global tablolar her yerde eşzamanlı yazmaları kabul eder ve sonradan son-yazan-kazanır ile uzlaştırır. MRSC global tabloları tam tersi ödünleşmeyi yapar: bir yazma, onaylanmadan önce Bölgeler arasında koordine edilmelidir, dolayısıyla iki Bölgenin aynı anda aynı öğeyi değiştirmesi gerçek bir çakışmadır — ve bir taraf sessiz bir üzerine yazma yerine bu istisnayı alır.

Neden olur

  • Aynı öğe birden çok Bölgeden eşzamanlı olarak yazılıyor — her ikisi de öğeyi güncellemek kendilerine aitmiş gibi ele alan iki uygulama dağıtımı.
  • Sıcak bir koordinasyon öğesi — her Bölge tarafından dokunulan sayaçlar, kilitler ya da tekil yapılandırma öğeleri doğal çakışma mıknatıslarıdır.
  • Bölgeler arası yeniden deneme fırtınaları — aynı mantıksal işlemin farklı Bölgelerden eşzamanlı yeniden denemeleri tekrar tekrar çakışmaya devam eder.

Nasıl düzeltilir

  1. Üstel geri çekilme ve titreşimle yeniden deneyin — çakışma anlıktır; diğer Bölgenin yazması tamamlandığında yeniden deneme ilerler. AWS bu hatayı yeniden denenebilir işaretler:

    // let the SDK's adaptive retry handle it, or catch and back off:
    catch (e) {
      if (e.name === 'ReplicatedWriteConflictException') return retryWithBackoff(op);
      throw e;
    }
  2. Öğelere bir ev Bölgesi verin — belirli bir anahtar için yazmaları bir Bölge üzerinden yönlendirin (kullanıcı ikametgahına, kiracıya ya da bölüme göre), diğer Bölgeleri çoğunlukla-okuma tutun. Bir öğeyi yalnızca bir Bölge değiştirdiğinde çekişme kaybolur.

  3. Eşzamanlı güncellemeleri değişmeli yapın — ayrı öznitelikler üzerinde atomik sayaç güncellemeleri (ADD / SET x = x + :n), tüm öğe üzerindeki oku-değiştir-yaz döngülerinden daha az çakışır.

  4. Yarışı kaybettikten sonra niyeti yeniden kontrol edin — diğer Bölge öğeyi değiştirdi; koşullu bir yeniden deneme (bir sürüm özniteliğinde ConditionExpression), yazmanızın yeni duruma karşı hâlâ geçerli olmasını sağlar.

Bir öğenin Bölgeler arasında değişmesini izlemek, veri önünüzdeyken çok daha kolaydır — DynoTable masaüstü uygulaması her çoğaltma Bölgesine bağlanır, böylece öğeyi yan yana karşılaştırabilirsiniz ve DynamoDB fiyatlandırma hesaplayıcısı, çoğaltılmış yazmaların maliyetini tahmin eder.

İlgili hatalar

References

En son 2026-07-13 tarihinde yukarıda bağlantısı verilen resmi AWS belgelerine karşı doğrulandı.

Console olmadan DynamoDB ile çalışın

DynoTable, DynamoDB için hızlı bir masaüstü istemcisidir — tablolara göz atın, SQL tarzı sorgular çalıştırın ve item'ları yerel olarak düzenleyin.