Durability, node kesintileri gibi anormal durumlar olduğunda hayatta kalan verinin en yüksek olasılıkta olmasını sağlar.
Couchbase’de varsayılan ayarlarda eğer yazılacak veri belleğe geldi ise başarılı olarak sonuç döndürür. Ama bu, riskli işlemlerde veya yazmanın kesin gerektiği durumlarda kesin sonuç vermez.
Couchbase Server’a yazma istemcileri isteğe bağlı olarak, Couchbase Server’a belirtilen belgeyi, işlenecek yazmayı düşünmeden önce cluster bellek ve / veya disk konumlarındaki birden çok düğümde güncellemesini bildiren dayanıklılık gereksinimlerini belirleyebilir
Gereksinimlerde belirtilen bellek ve / veya disk konumu sayısı arttıkça, elde edilen dayanıklılık düzeyi de artar.
Eğer verinin yazmasında kesinlik sağlanmaz ise hata döndürmesi ve yapılan işlemelerin geri alınması sağlanabilir.
Couchbase Server 2 replikaya kadar durability’i destekler. 3 replikada desteklemez.
2 tür yazma işlemi bulunmaktadır. İlki verinin kesin yazıldığına bakılmadan başarılı döndüren , ikincisi ise yazma işlemi kesinlikle diske yazıldıktan sonra başarılı olandır.
Reguler Write(Asynchronous)
Bu yazma işleminde verinin kaybının çok öneminin olmadığı durumlarda bellek içine geldikten sonra başarılı olarak dönen yazma işlemidir. Örnek vermek gerekirse bir sensöre dakikada binlerce veri gelsin. Bu durumda on binlerce veri geldiğini ve kayıp olmasının çok etkilemediği durumdur.
Durable Write(Synchronous)
Bu işlem veri kaybının yüksek düzeyde olumsuzluğa neden olacağı durumlarda kullanılır. Örnek vermek gerekirse finansal işlemlerde bu yazma işlemi kullanılmalıdır.
*Tahmin edildiği üzere kesin sonuç dönen yazma işleminde diğerine göre bir yavaşlık söz konusu olmaktadır. Bu nedenle uygulama tasarımcısı bu yavaşlığı ve kesinliği hesaba katarak seçimini yapmalıdır.
Client tarafından belirlenen durability gereksinimleri bucket için tanımlanan replikaların sayısına bağlı olarak durability’nin gerekli olduğu yapılandırılmış data servisleri node’larının sayısını belirtmek için ‘Majority’ kavramını kullanır. Kısaca açıklamak gerekirse Durability write seviyeleri olarak açıklanabilir.
Durability Gereksinimleri :
İstemci tarafında belirtilen dayanıklılık gereksinimleri nelerdir?
majority ==> Veri, Data servis(Memory) node’larının çoğuna çoğaltılmak zorundadır.(Yani bucket’a ayrılan bellekte tutulur.)
majortiyAndPersistActive ==> Veri, Data servislerinin çoğuna(Memory) çoğaltılmak zorundadır. Ayrıca veriler için etkin vBucket node’unun diskinde de kaydedilmek zorundadır.
persistToMajority ==> Veri Data servislerinin çoğuna ve disklerine çoğaltılmak zorundadır.
“Time Out” Durability gereksinimlerinin karşılanması gereken milisaniye sayısıdır. SDK, varsayılan olarak 2500 değerini belirtir.
Durable Write işlemi atomik bir işlemdir. Kalıcı yazım işlemi tam olmadan önce okuma işlemi yapılırsa yazma işlemi bitmeden önceki değer gözükmektedir. Eğer aynı anda yazma işlemi yapıldıysa ilk yazmaya başlayanın işlemi bitmeden sonrakinin yazması işleme sokulmaz ve hata mesajı döndürülür.
Şimdi adım adım okuma-yazma işlemlerinin durumlarını inceleyelim.
-İlk olarak şunu aklımızda tutalım. Disk içinde value’miz ‘a’ değerini tutmakta.
- 1. Adımda Client1 ‘imiz value değerimizi ‘b’ yapmak istiyor ve bu yazma işleme sokuluyor.
- 2. Adımda yazma işlemimiz başlıyor.
- 3. Adımda Client2 ‘miz value değerimizi istiyor. Client1 ‘in yazma işlemi hala sonlanmadığından bir önceki değer olan ‘a’ değerimizin döndüğünü görüyoruz.
- 4. Adımda Client3 ‘ümüz value değerini değiştirmek istiyor. Ama hala Client1 ‘in yazma işlemi sonlanmadığından ‘IN PROGRESS’ diye mesaj döndürüyor.
- 5. Adımda yazma işlemimiz bitiyor ve artık value değerimiz ‘b’ oldu.
- 6. Adımda Client2 tekrardan value değerimizi istiyor ve bu sefer ‘b’ değerimizin döndüğünü görüyoruz.
- **Eğer yazma işlemi iptal edilirse bellek ve disklerdeki değiştirilen tüm değerler eski haline geri döndürülür.
Şimdi gelin bir de hata senaryolarını gözden geçirelim.
1. Hata (Sunucu zaman aşımına uğrarsa)
Aktif node durable write’ı iptal eder ve tüm replika node’larına bekleyen yazmayı iptal etmelerini söyler . Ardından da client’a yazma işleminin belirsiz olduğuna dair hata mesajı döndürür.
2. Hata (Yazma işlemi devam ederken replika node’u hata alırsa)
Eğer yeteri kadar replika node tanımlanırsa yazma işlemi devam eder. Aksi taktirde aktif node’umuz zaman aşımı dolana kadar bekler ve yazma işlemini iptal eder. Client için de yazmanın belirsiz olduğuna dair hata mesajı döndürür.
3. Hata (Yazma işlemi sırasında aktif node hata alırsa)
Bu durumda aktif node çökerse ve replika node varsa replikalardan birisi aktif duruma geçer ve yazma işleminin ne kadar geliştiğine bağlı olarak yazma işlemi tamamlanır.
4. Hata (Yazma işlemi sırasında başka yazma işlemi yapılmaya çalışılırsa)
Client yazma işleminin şu an devam edemeyeceğine ve başka işlemin devam etmekte olduğuna dair ‘SYNC_WRITE_IN_PROGRESS’ iletisi alır.
Yazma garantisi ;
*Aktif yazma işlemi ‘Rebalance’ sırasında da devam etmektedir.
*Eğer bucket için 3 replika tanımlandıysa ve Durable write işlemi yapılmak istenirse Client için ‘EDurabilityImpossible’ mesajı döndürülür.
*Eğer yazma işlemi persistToMajority seviyesinde gerçekleşiyorsa ve cluster içinde yeteri kadar dağılım olmadan otomatik failover işlemi gerçekleşirse replika VBucket başka yerde bulunmadığından verilerin kaybı ile sonuçlanır.
Örnek vermek gerekirse ; Bir bucket için 2 tane replikası olsun. 2 replika 1 de aktif olmak üzeri 3 node’da bilgi tutulacaktır. Kalıcılığın olması için gereken sayı 2 node’da datanın olmasıdır ve bu 2 node’a yazıldıktan sonra bu 2 node cevap vermiyorsa ve 3. node a yazılırken failover olursa yazma işlemi gerçekleşmez ama failover öncesi başarı durumunu sağladığı için client’a yanlış mesaj döner. Bunun engellenmesi için 2 node değilde sadece 1 node başarısız olması yazmanın doğruluğunu karşılar.
Tek replika durumunda yazma işleminin garantiliğini bir kez daha kontrol edelim.
‘majority’ Level – 1 Replika
Hata;
Aktif node başarısız olur ve otomatik failover başladı.
Sonuç;
Yazma işlemi sırasında etkin node’umuz ile bağlantımız koptu. Verimiz aktif düğümün belleğinden kayboldu ama replika düğümün belleğinde bulunmakta. Replika vBucket’larımız aktif duruma yükselir ve veri başarılı şekilde yazılır.
‘majorityAndPersistActive’ Level – 1 Replika
Hata 1;
Aktif node başarısız oldu ve otomatik failover başladı.
Sonuç 2;
Veri aktif node’un bellek ve diskinden kayboldu ama replika node’un belleğinde var. O zaman replika vBucketler aktif duruma geçer ve yeni veriler kurtulmuş olur.
——-
Hata 2;
Aktif node başarısız oldu ve otomatik failover öncesi yeniden bağlantı sağlandı.
Sonuç 2;
Veriler aktif node’un belleğinden silinir ama diskinde bulunduğu için aktif node yeniden çalışmaya başladığı anda veri kurtarılır.
‘persistToMajority’ Level – 1 Replika’
Hata 1;
Aktif node başarısız oldu ve otomatik failover başladı.
Sonuç 1;
Veriler aktif node’un belleğinden ve diskinden silinir ama replika node’un bellek ve diskinde bulunduğundan replika vBucket’lar aktif duruma geçer ve veri korunmuş olur.
——-
Hata 2;
Aktif node başarısız oldu ve otomatik failover öncesi yeniden bağlantı sağlandı.
Sonuç 2;
Veriler aktif node’un belleğinden silinir ama diskinden durmaya devam eder. Böylelikle aktif node yeniden başladığı anda veriler kurtarılmış olur.
——-
Hata 3;
Aktif node başarısız oldu ve otomatik failover oldu. Ardından aktifleşen node ile bağlantı koptu ve yeniden başladı.
Sonuç 3;
Veriler aktif node’un bellek ve diskinden kayboldu ama replika node’un belleğinde ve diskinde bulunur ve aktif duruma geçer. Ardından aktif hale geçen düğüm yeniden başlatıldığında yeni veriler diskte tekrardan erişilebilir olur.
Önemli Not : 2 Replika yapılandırıldığında otomatik failover’ın garantili koruma ile çakışmamasını sağlamak için yönetici müdahalesi olmadan gerçekleşebilecek maksimum sıralı failover sayısı olarak 1’i seçin.
2 Replikalı korumada yazma garantileri tek replika ile aynıdır. Sonuçta ikisinde de çoğunluk 2 replika ile sağlanmaktadır.
