10. Redis Handling Failure

Redis, ilişkisel databaselerin aksine ACID prensibiyle çalışmayan bir NoSql çözümü olduğu için ve verileri memoryde tuttuğu için, olası bir felaket senaryosunda veri kaybetmemek için kendimizi her türlü felaket senaryosuna hazırlamamız gerekir. Bu yazımda redis için olası felaket senaryolarında ne gibi önlemler alabileceğimizden bahsetmeye çalışacağım

1.Persistency Ayarlarını Doğrulamak                 

Rediste herhangi bir sıkıntı sebebiyle veri kaybıyla karşılaşma ihtimalimize karşı güvenlik önlemlerimizden biri persistence ayarlarımız olabilir. Redis persistence’ı iki farklı opsiyon ile destekler. Snapshotting ve Append-only file. Snapshotting adından da anlaşılacağı üzere bizim belirlediğimiz belli zaman aralıklarıyla redisteki verinin snapshotını alır ve diske kaydeder. Append-only file ise redise gelen her commandı kaydeder yani real time’a yakın bir veri koruyuculuğu sağlar. Bu sayede herhangi sebepten bir veri kaybı yaşadığımızda bu opsiyonlar ile verilerimizi geri yükleyebiliriz.

Bu aof dosyasında bozulma olması durumunda redis bizlere bu dosyaları fixleyecek opsiyonlar da sunmaktadır. Bunlar redis-check-aof ve redis-chck-dum’dır. Redisin pc içerisinde yüklendiği klasöre girdiğinizde bu iki opsiyonu exe formatında göreceksiniz. Eğer ki redis-check-aof’a -fixi bir argüman olarak geçersek, command redisi fixleyecektir. Basit bir işlemdir. Tüm AOF file taranır ve tamamlanmayan ya da yanlış olan comandlar tespit edilir. İlk sıkıntılı komutu bulanana kadar, son çalıştırılan koddan hemen öncesini trim edilerek gidilir. Ancak şuan bozulmuş snapshotı düzenleyecek bir metot maalesef  yok.

Rediste bu şekilde yedeğini aldığımız dataları kontrol ettiğimizde ve doğruluğundan emin olduğumuzda kurtarma işlemini yapabiliriz.

2.Çöken Bir Master Makineyi Değiştirmek

Bazı zamanlar makinaların bir sebepten inme durumu söz konusu olabilir. Bu sebep kötü makine, kötü memory belki de elektriklerin gitmesi bile olabilir. Ancak sebepleri bir yana, en nihayetinde redis serveri değiştirmemiz gerekecektir. Eğer bir grup redis serverını replicasyon ve persistence ile koşturuyor isek bu durumla mücadele edebilecek şansımız var demektir.

Bir örnek senaryo üzerinden ilerleyelim.

Master olarak hareket eden A makinamız, bir de slave olarak davranan B makinamız olsun. A bir sebepten dolayı ağdan kopmuş olsun ve bir de C makinamız olsun. Bu durumda plan gayet basit. B makinasına SAVE keywordü üzerinden güncel snapshot üretmesini söyleyeceğiz. Bu snapshotu C makinasına kopyalayacağız. Ve daha sonra redisi C makinasında ayağa kaldıracağız. Ve en sonunda B makinasına Cnin slaveyi olmasını söyleyeceğiz. Ya da bir alternatif yol olarak da slaveyi yeni mastera çevirmek isteyebilirz.

Her iki durumda da, Redis kaldığı yerden devam edebilecektir. Bundan sonraki tek işimiz, istemci yapılandırmamızı uygun sunuculara okumak ve yazmak için güncellemek ve isteğe bağlı olarak Redis’i yeniden başlatmamız gerekirse disk üstü sunucu yapılandırmasını güncellemektir. Tabi bu gibi ayarları ile uğraşmak istemiyorsak bunun yerine bir sonraki yazımda anlatacağım redis sentinel’i de kullanabiliriz.