DynamoDB Global Tables: Çok Bölgeli Replikasyon Açıklaması
Bir global tablo, birden fazla AWS bölgesinde replike edilmiş tek bir DynamoDB tablosudur ve her replika yazılabilirdir. DynamoDB bunları otomatik olarak senkron tutar — kendi replikasyonunu çalıştırmadan, her bölgede düşük gecikmeli yerel okuma ve yazma ile bölgeler-arası olağanüstü durum kurtarma elde edersin.
Denetim günlüğü senaryosunda, bir AB müşterisi verisinin eu-west-1'de canlı
olmasını gerektirirken, geri kalanı us-east-1'de çalışır. Ve uyumluluk açısından
kritik bir günlük olarak, tam bir bölgesel kesintiden sağ çıkması gerekir. Bir
global tablo, her ikisini de tek bir özellikle yanıtlar.
DynamoDB Global Tables nasıl çalışır?
DynamoDB Global Tables, birden fazla AWS bölgesinde replike edilmiş tek bir tablodur ve her replika okunabilir ve yazılabilirdir. DynamoDB bunları asenkron replikasyon üzerinden otomatik olarak senkronlar, çakışmaları son-yazan-kazanır ile çözer. Bölge başına düşük gecikmeli yerel okuma ve yazma artı bölgeler-arası olağanüstü durum kurtarma elde edersin; bu, DynamoDB'nin %99,999 kullanılabilirlik SLA'sını destekler.
- Çok bölgeli, aktif-aktif. Her replika tamamen okunabilir ve yazılabilirdir; herhangi bir bölgedeki yazmalar diğerlerine yayılır.
- Varsayılan modda, replikasyon asenkron ve bölgeler arasında — tipik olarak bir saniye içinde, ama anında değil. (Bir güçlü tutarlılık modu da vardır — aşağıya bak.)
- Çakışmalar son-yazan-kazanır ile çözülür. İki bölgede aynı öğeye eş zamanlı yazmalar en yenisine uzlaşır.
- %99,999 kullanılabilirlik SLA'sını destekler — çok bölgeli bir global tablo, DynamoDB'nin en yüksek kullanılabilirlikli yapılandırmasıdır.
Sorun: bir bölge yeterli değil
Tek bölgeli bir tablonun, denetim günlüğünün kabul edemeyeceği iki sınırı vardır.
Birincisi, veri yerleşimi: bir AB müşterisinin olayları AB'de saklanmalı, ama
uygulaman ABD'de çalışıyor. İkincisi, olağanüstü durum kurtarma: us-east-1
kesinti yaşarsa, tek bölgeli bir denetim günlüğü, süre boyunca okunamaz ve
yazılamaz olur — tam da olanların kaydına en çok ihtiyaç duyduğun anda.
İkisini de kendin inşa etmek — bölgeler-arası replikasyon, yük devretme, çakışma işleme — büyük, hataya açık bir projedir. Global tablolar bunu bir yapılandırma seçeneği yapar.
Replikasyon mekaniği
Tabloya bir replika bölgesi eklersin; DynamoDB orada bir kopya oluşturur ve tüm replikaları senkron tutar.
Varsayılan (MREC) davranışını iki tutarlılık kuralı tanımlar:
- Bölgeler-arası replikasyon asenkrondur.
us-east-1'deki bir yazma yerel olarak onaylanır, sonraeu-west-1'e yayılır — genellikle bir saniye içinde, ama bir yazmadan hemen sonra diğer bölgedeki bir okuma onu henüz görmeyebilir. (Varsayılan MREC modunda, güçlü yine çalışır, ama yalnızca tek bir bölge içinde.) - Çakışmalar son-yazan-kazanır. Aynı öğe iki bölgede neredeyse aynı anda yazılırsa, DynamoDB en geç zaman damgalı yazmayı tutar ve diğerini atar.
İşlenmiş bir örnek: aynı zamanda DR olan bir AB replikası
Denetim günlüğü tablosunun bir replikası olarak eu-west-1'i eklersin. Şimdi:
| write region | item | visible in | |
|---|---|---|---|
| us-east-1 | TENANT#acme | EVENT#…#a1 | both regions (~1s lag to EU) |
| eu-west-1 | TENANT#bmw | EVENT#…#e7 | both regions (~1s lag to US) |
AB müşterisinin uygulaması yerel eu-west-1 replikasına yazar ve ondan okur —
düşük gecikme ve bölge içinde yerleşik veri. Yerleşimi sağlayan aynı replikasyon,
olağanüstü durum kurtarma olarak da ikiye katlanır: us-east-1 çökerse,
eu-west-1 replikası yine tüm günlüğü tutar ve trafiği sunar; ona yük devredersin.
Denetim günlüğü yalnızca-ekle ve kiracı başına partition'lı olduğu için, son-yazan-kazanır burada esasen sorun değildir — belirli bir kiracının olayları tek bir bölgeden yazılır ve olay anahtarları benzersizdir, dolayısıyla iki bölge aynı öğede nadiren yarışır. Bu şans değil; yalnızca-ekle bir günlüğün global tablolar için en temiz uyumlardan biri olmasının nedeni budur. Değişebilir bir sayaç ise, buna karşın, eş zamanlı bölgeler-arası yazmalar altında dikkat isterdi.
Bunu DynoTable'da yapın
Bir replika ekledikten sonra, verinin gerçekten yeni bölgeye indiğini ve kaynakla
eşleştiğini doğrulamak istersin — AB replikasının gerçekten acme'nin olaylarını,
doğru özniteliklerle tuttuğunu ve gecikmediğini.
DynoTable herhangi bir bölgeye kendi kimlik bilgileriyle bağlanır, böylece bir
pencereyi us-east-1'e, diğerini eu-west-1'e yöneltip aynı kiracının öğelerini
yan yana karşılaştırarak replikasyonu doğrulayabilirsin.

Her replikaya karşı çalıştıracağın bölge başına sorguların prototipini DynamoDB Expression Builder'da oluşturabilirsin.
Tuzaklar ve sonraki adımlar
- Bölgeler arasında kendi-yazdığını-okuma yapma. Replikasyon gecikmesi, bir bölgedeki bir yazmanın ~bir saniye boyunca başka bir bölgede görünmeyebileceği anlamına gelir. ABD'ye yazıp hemen AB'den okuyup onu görmeyi bekleme. Varsayılan MREC modunda, güçlü tutarlı okumalar yalnızca tek bir bölge içinde çalışır; MRSC güçlü okumaları bölgeler arasına genişletir.
- Son-yazan-kazanır sessizce veriyi düşürür. İki bölgede eş zamanlı yazılan değişebilir öğeler için, kaybeden hiçbir hata olmadan atılır. Yalnızca-ekle veya öğe başına tek yazan tasarımlar (bu denetim günlüğü gibi) sorundan kaçınır; paylaşılan değişebilir durum, çakışma-farkında bir tasarım ister.
- Her replika maliyetlidir. Her bölge tam bir kopya saklar ve kendi kapasitesi ile depolamasını faturalandırır — bir replika maliyeti kabaca ikiye katlar. Gerçek bir yerleşim veya DR ihtiyacı için bölge ekle, varsayılan olarak değil.
- Yedekler replika başınadır. Geri yüklenen bir global tablo, bağımsız bir tablo olur — kurtarmayı bölge başına planla. Bkz. yedekleme ve zaman-noktası kurtarma.
Global tablolar bir bölgeyi kaybetmeye karşı korur. Son operasyonel kaygı, veriyi kaybetmeye karşı korumaktır — kötü bir dağıtım veya kazara silme — yedekleme ve zaman-noktası kurtarma ile.
Birden fazla bölgeye bağlanmak ve global tablo replikalarının aynı veriyi tuttuğunu doğrulamak için DynoTable'ı indir.


