REDIS PERSISTENCE

Bilgisayar bilimlerinde persistence “veri kalıcılığı”; verinin, oluşturulduğu işlemden sonra da tutulması özelliğidir. Böyle bir özellik olmasaydı, veri sadece RAM’de bulunabilirdi ve bilgisayarın kapanması gibi RAM’in güç kaybına uğradığı durumlarda kaybolurdu.

Redis iki tip persistence özelliğini kullanıcılarına sunar. Bunlar RDB snapshot ve AOF özellikleridir. İki persistence özelliğinin de avantajları ve dezavantajları bulunmakla birlikte ihtiyaçlara göre seçilip kullanılabilir hatta iki özellik aynı anda da kullanılabilir. İstenildiği takdirde bu iki persistence özelliği kapatılıp verilerin sadece redis serverı ayaktayken kalıcı olmaları da sağlanabilir. Redisin bize sunduğu bu iki persistence özelliğini incelemeye başlayalım.

1.RDB SNAPSHOTTING

RDB snapshotting özelliği belli zaman aralıklarıyla redisteki verilerin bir görüntüsünü diske yazmak için kullanılan ayardır ve redis için varsayılan aktif olarak gelir. RDB snapshotlar hızlıdır çünkü ana threadde çalışmazlar ve her redis işleminde değil belli aralıklarla oluşturulurlar.

RDB snapshot kullanmanın avantajları

• RDB snapshottingi db backupları gibi düşünebilirsiniz. Bu, disaster durumunda, veri kümesinin farklı sürümlerini kolayca geri yüklemenizi sağlar.
• RDB, büyük datasetleriyle AOF ile karşılaştırıldığında daha hızlı yeniden başlatmalara izin verir.

RDB snapshot kullanmanın dezavantajları

• RDB snapshotting özelliğiyle veri kaybetme olasılığınız her zaman vardır. RDB snapshotın mantığı belli aralıkla rediste belli sayıda key’in değişip değişmediğini kontrol ederek bu da göre snapshot almak üzerine kuruludur. Örneğin, bu aralığın 5 dakikada bir olduğunu varsayarkan ilk snapshottan sonraki 5 dakikalık aralığın 4. dakikasında server down olursa o 4 dakikaya kadar olan verileriniz henüz backup alınamadığı için kaybolur.

RDB snapshot özelliğini aktif/pasif etmek, snapshot sıklığını değiştirmek veya konfigurasyonlarını değiştirmek için redisin kurulu olduğu klasörde redis.conf uzantılı dosya üzerinde oynamalar yapmalısınız. Bu dosya redisin configurasyonlarını içeren dosyadır. Dosyayı açtıktan sonra, config başlıkları arasından snapshottingin olduğu kısma gelip, snapshot configurasyonlarını görebilirsiniz.

save 900 1
save 300 10
save 60 10000   ifadesi belli aralıklarla minimum hangi sayıda değişiklikle karşılaşılırsa verilerin snapshot’ının alınacağının ayarlarıdır. Default olarak gelen ayarlar, 15 dakikada bir en az 1 key değiştiyse, 5 dakikada bir en az 10 key değiştiyse 60 saniyede bir en az 10000 key değiştiyse snapshot alınacağını bize söylüyor. Bu şekilde farklı aralıklar verilmesi key değişikliğinin yoğunluğuna göre, veri kaybının az olması için key change kontrolünü de değiştirmek amacını taşır. Eğer bu save satırlarını yorum satırına alırsanız da RDB snapshot özelliğini kapamış olursunuz.

RDB Snapshots Nasıl çalışır?

Redis’in dataseti diske yazması gerektiğinde :

• Redis calling processinde fork işlemi uygulanır. Böylece bir child ve bir parent süreci oluşur.
• Child dataseti geçici bir RDB file’ına yazar.
• Child process bu yazma işlemini bitirdiğinde yeni .rdb file eskisiyle yer değiştirilir.

config dosyasında her config başlığıyla ilgili güzel açıklamalar bulabilirsiniz. Ben de burada configte detaylandırılmış olan bir kaç özelliği burada da özetleyeceğim.

stop-writes-on-bgsave-error yes  : Eğer ki RDB snapshot özelliği aktif olmasına rağmen redis verileri diske yazmakla ilgili bir problem yaşarsa, redis server komut yazma işlemini durdurur. Böylece kullanıcı diskte verilerin doğru depolanmadığını anlar ve bir sorunun önüne geçilmiş olur. Arka planda çalışma işlemi tekrar başlarsa redis yazma işlemlerini otomatik olarak tekrar çalıştırır. config dosyasındaki bu ifadenin yes/no olarak ayarlanması bu özelliği aktif/pasif yapar. No olarak ayarlandığında rediste verilerin diske kaydedilmesi sırasında bir problem olsa dahi, redis yazma işlemine devam edebilir.

rdbcompression yes : RDB file’ında depolanan string objelerini LZF algoritmasını kullanarak sıkışırır. Genel olarak bir dezavantajı olmadığından default olarak yes’e ayarlanmıştır

dbfilename dump.rdb : DB’nin atılacağı dosya adını belirler.

2.APPEND ONLY MODE

Varsayılan olarak Redis RDB snapshots ile asenkron olarak veri setini diske atar. Bu mod birçok uygulamada yeterli derecede iyidir. Ancak elektrik kesintisi gibi sorunlarda, birkaç dakikalık yazma kaybına neden olabilir.

Append only mode, çok daha durable persistence modudur. AOF ile persistence sağlanmak istendiğinde, AOF rediste gerçekleşen her commandı loglayacak ve her yeni command eklendiğinde bu loglara yeni commandı ekleyecektir. Her yeni gelen comment bu log dosyasını update edeceğinden olası bir felakette maksimum veri kaybı 1 command seviyesinde olacaktır.

AOF ve RDB kalıcılığı aynı anda sorunsuz olarak etkinleştirilebilir. AOF etkinleştirilmişse, Bir felaket sonrası yeniden yüklemede redis ilk AOF’yi yükler, bu da daha eksiksiz veri dönüşünü garanti eder.

AOF kullanmanın dezavantajları

•  AOF dosyaları eşit veri setleri için RDB snapshots dosyalarından daha büyüktür.
• Kesin fsync politikasına bağlı olarak AOF RDB’den daha yavaş olabilir.

AOF Nasıl Çalışır?

Redis calling processinde fork işlemi uygulanır. Böylece bir child ve bir parent süreci oluşur.

• Child dataseti geçici bir AOF file’ına yazar.
• Parent, tüm yeni değişiklikleri bellek içi arabellekte biriktirir. (ancak aynı zamanda eski değişiklikleri yalnızca eski ekleme dosyasına da yazar; bu nedenle yeniden yazma işlemi başarısız olursa güvende oluruz).
• Child dosyayı yeniden yazmayı tamamladığında, parent bir sinyal alır ve child tarafından oluşturulan dosyanın sonuna the in-memory buffer ekler.
• Redis atomik olarak eski dosyayı yenisine dönüştürür ve yeni dosyaya yeni veriler eklemeye başlar.

Append only özelliğiyle ilgili redis.conf dosyasında bulunan optionların da detaylı açıklamasını conf dosyasında bulabileceğiniz gibi, aşağıda ben de kısaca bir özet geçmiş olayım 🙂 .

appendfilename “appendonly.aof”  : Command loglarının saklanacağı dosyayı belirler

appendfsync always    :   Bu config append only modun önemli configlerinden olmakla birlikte 3 opsiyon alır. Bunlar everysec / always / no  dır. Bunları sırasıyla inceleyelim.(fsync() işletim sistemini diske data yazması için çağıran fonksiyondur. )

always : Eğer  appendfsync’i always olarak ayarlarsak, redis servera gelen her yazma işleminde diske yazma yapacak ve bu da olası bir felaket durumunda veri kaybımızı minimuma indirecektir. Maalesef, redis servera gelen her write işlemi ile birlikte diske yazma yaptığımız için, dönen bir disk için yaklaşık 200 yazma/saniye ve SSD için birkaç on binlik disk performansı ile sınırlıyız. Redisi yavaşlatan ancak güvenli bir seçimdir.

everysec : Verileri güvende tutmak ve yazma performansımızı yüksek tutmak arasında orta noktayı bulmak için appendfsync everysec özelliğini de ayarlayabiliriz. Bu ayar ile birlikte veriler her saniyede bir log günlüğüne append edilir. Bu durumda serverdaki herhangi bir çökme durumda bize max 1 saniyelik veri kaybettirir.  Ayrıca, diskin gerçekleşmekte olan yazma hacmine ayak uyduramaması durumunda, Redis sürücünün azami yazma oranına uyması için yavaşlar.

  no : Redis, her şeyi işletim sistemine bırakarak açık bir dosya senkronizasyonu gerçekleştirmez. Bu durumda hiçbir performans sıkıntısı olmaz, ancak eğer sistem bir şekilde veya başka bir şekilde çökerse, bilinmeyen ve tahmin edilemeyen miktarda veri kaybederiz.

no-appendfsync-on-rewrite no   : AOF fsync policy always ya da everysec olarak ayarladığında ve background saving process diske göre çok fazla I/O işlemi gerçekleştirdiğinde, redis fsybc() callarını blocklayabilir. Bu sorunu hafifletmek için, BGSAVE veya BGREWRITEAOF devam ederken, fsync () işlevinin ana işlemde çağrılmasını önleyen aşağıdaki seçeneği kullanmak mümkündür.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb    : Redis, AOF log boyutu belirtilen yüzdeye göre büyüdüğünde otomatik olarak BGREWRITEAOF ‘i çağırarak log dosyasını otomatik olarak yeniden yazabilir. Redis her yazma işleminden sonra dosya boyutunu hatırlar ve base size ile bunu karşılaştırır. Eğer dosya boyutu base sizedan büyük ise yeniden yazma işlemi tetiklenir.

AOF Rewriting

Zaman içinde AOF dosyası büyüyebilir, bu nedenle Redis “AOF Rewriting” adı verilen bir işlemle dosyayı küçültür. Bu işlem sırasında gereksiz komutlar atılır ve AOF dosyası daha verimli hale getirilir. Redis’te AOF yeniden yazma (AOF rewriting) işlemi sırasında “gereksiz komutlar” ifadesi, veri tabanının son durumuna ulaşmak için artık gerekli olmayan veya aynı sonucu daha az komutla elde edilebilecek komutları ifade eder. Bu komutlar, veritabanının son durumunu korumak için AOF dosyasından çıkarılabilir veya optimize edilebilir.

Neden RDB var ?

Redis’e yazılan her komut, diskteki log dosyasına eklenir vr log dosyası sürekli olarak büyür. Zamanla, büyüyen bir AOF diskinizin alanının tükenmesine neden olabilir, ancak daha genel olarak, yeniden başlatmanın ardından Redis AOF’taki her komutu sırayla yürütecektir. Büyük AOF’leri kullanırken, Redis’in başlaması çok uzun sürebilir.

Hangisini Kullanmalıyız?

• Eğer, PostgreSQL’in size sağlayabilecekleri ile karşılaştırılabilir yüksek bir veri güvenliği derecesi istiyorsanız, her iki kalıcılık yöntemini de birlikte kullanmanız gerektiğidir.
• Verileriniz sizin için önemliyse, ancak yine de felaket durumunda birkaç dakikalık veri kaybı yaşayabilirseniz, RDB’yi tek başına kullanabilirsiniz.
• Yalnız AOF persistence yönetimini kullanan birçok kullanıcı var, ancak zaman zaman bir RDB anlık görüntüsünün olması, zaman zaman veritabanı yedeklemesi yapmak, AOF motorunda hata olması durumunda belli süre aralıklarındaki backuplara dönüş yapmak, daha hızlı yeniden başlatmalar için ideal olabilir.

Redis bu sebeplerden dolayı (özellikle 3. madde) uzun vadeli plan olarak RDB snapshot ve AOF özelliklerini tek bir model altında toplamayı düşünüyor.