Redis kalıcılığı: RDB, AOF ve yedekleme nasıl ayarlanır?

Redis kalıcılığında hangi seçenekler var?

Redis verisini bellekte tutar; sunucu kapandığında ya da çöktüğünde diske yazılmamış her şey kaybolur. Kalıcılık (persistence), belleğin içeriğini kalıcı depolamaya yazma yöntemidir. Redis belgesi şu seçenekleri sıralar: RDB, AOF, kalıcılığı tamamen kapatmak ve RDB ile AOF'yi birlikte kullanmak.

RDB (Redis Database), veri kümesinin belirli aralıklarla alınan anlık görüntüsüdür (snapshot). AOF (Append Only File) ise sunucunun aldığı her yazma işlemini bir günlüğe ekler; açılışta bu günlük yeniden oynatılarak veri yeniden kurulur. Kalıcılığı kapatmak, Redis önbellek olarak kullanılırken tercih edilebilir; kayıp tolere ediliyorsa disk yazma maliyeti de ortadan kalkar.

Redis belgesinin genel yönlendirmesi şöyledir: PostgreSQL'e yakın düzeyde veri güvenliği istiyorsanız her iki kalıcılık yöntemini birlikte kullanın. Birkaç dakikalık veri kaybını göze alabiliyorsanız yalnız RDB yeterlidir. AOF'yi tek başına kullananlar çok olsa da belge bunu önermez, çünkü zaman zaman alınan bir RDB anlık görüntüsü yedekleme, hızlı yeniden başlatma ve AOF motorundaki olası hatalara karşı iyi bir güvencedir.

RDB'yi yapılandırma: snapshot nasıl alınır?

Varsayılan olarak Redis veri kümesini dump.rdb adlı ikili bir dosyaya kaydeder. Otomatik anlık görüntü, redis.conf içindeki save ayarıyla tanımlanır: "N saniyede en az M değişiklik olduysa kaydet" biçimindedir.

save <saniye> <değişiklik-sayısı>

Birden çok save satırı tanımlayabilirsiniz; sık değişen veride kısa aralıklar, durağan veride uzun aralıklar mantıklıdır. Elle anlık görüntü için SAVE ya da BGSAVE komutları kullanılır; BGSAVE işi arka planda yürüttüğü için istemcileri bekletmez ve üretimde tercih edilir.

Belgeye göre RDB şöyle çalışır: Redis süreci çatallanır (fork), çocuk süreç veri kümesini geçici bir RDB dosyasına yazar, bittiğinde eski dosyanın yerine koyar. Ana süreç disk işlemi yapmaz, bu da RDB'nin performansı koruma avantajıdır. Yazma sırasında dosya geçici adla oluşturulur ve tamamlanınca atomik olarak yeniden adlandırılır; bu yüzden bir RDB dosyası çalışan sunucudayken bile güvenle kopyalanabilir.

RDB'nin bedelleri vardır. İlki veri kaybı penceresi: çökme anında son anlık görüntüden sonraki yazmalar gider, yani kaybedilecek şey birkaç dakikalık veri olabilir. Diğeri fork maliyeti: veri kümesi büyük ve işlemci zayıfsa fork, istemcilere birkaç milisaniye, çok büyük veride bir saniye kadar hizmet vermeyi durdurabilir. Bu bedeller kabul edilebilirse RDB, basit ve kompakt bir yöntemdir.

AOF'yi yapılandırma: fsync politikası ve yeniden yazım

AOF'yi açmak tek satırdır:

appendonly yes

Bundan sonra veri kümesini değiştiren her komut dosyaya eklenir. Dayanıklılığı belirleyen ayar appendfsync'tir ve belgeye göre şu seçenekleri vardır:

• always: her yazmada fsync yapar. Çok güvenli, çok yavaş. Belgeye göre birden çok istemcinin işlemleri toplu yazılıp tek fsync ile kaydedilir.
• everysec: saniyede bir fsync yapar. Önerilen ve varsayılan seçenektir; felakette bir saniyelik veri kaybı olabilir.
• no: fsync'i işletim sistemine bırakır. En hızlı, en riskli seçenektir.

Çoğu üretim yükü için everysec iyi bir denge sunar. Her yazmayı garanti etmeniz gereken bir iş akışınız varsa always'i yavaşlığı ölçerek değerlendirin.

AOF dosyası zamanla büyür; aynı sayaç tekrar tekrar artırılırsa veri kümesinde tek anahtar kalsa da günlükte her artış için ayrı kayıt birikir. Çözüm yeniden yazımdır (rewrite): Redis arka planda mevcut veri kümesini kurmak için gereken en kısa komut dizisini yazar ve bittiğinde yeni dosyaya geçer. Elle BGREWRITEAOF ile başlatabilir, otomatik tetikleme için auto-aof-rewrite ayarlarını kullanabilirsiniz.

Belgeye göre güncel sürümlerde AOF çok parçalıdır: bir temel dosya (veri kümesinin anlık görüntüsü) ve ardından gelen artımlı dosyalar tek bir dizinde durur ve bir manifest dosyasıyla izlenir. Dizin adı appenddirname ayarıyla belirlenir. Yedeklemede tek bir dosya yerine bu dizini düşünmeniz gerekir.

Hangi kombinasyonu seçmeli?

Karar, "ne kadar veri kaybı kabul edilebilir" sorusuna bağlıdır.

• Redis yalnızca önbellek, veri başka yerde yeniden üretilebiliyor: kalıcılığı kapatmak mantıklı olabilir. Açılışta boş başlamanın kabul edilebilir olduğundan emin olun.
• Birkaç dakikalık kayıp tolere edilebilir, yedekleme ve hızlı yeniden başlatma önemli: yalnız RDB.
• Kayıp kabul edilemez ya da yaklaşık bir saniyelik pencere istenir: RDB ve AOF birlikte, appendfsync everysec ile.
• Her yazmanın diske ulaşmasını gerektiren nadir durumlar: AOF ve always; performans maliyetini önceden ölçün.

Her iki yöntem birlikte açıksa, sunucu yeniden başladığında belgeye göre veri kümesini AOF dosyasından kurar, çünkü AOF en eksiksiz kayıt olarak kabul edilir. RDB ise yedekleme ve hızlı geri yükleme için ayrıca değer taşır.

Kalıcılık tek başına yedek değildir. Disk bozulabilir, bulut örneği kaybolabilir; aynı makinedeki dosya aynı felaketten etkilenir. Kalıcılık çökme ve yeniden başlatmaya karşı korur, yedekleme ise felakete karşı.

RDB'den AOF'ye canlı geçiş

Çalışan bir sunucuda yalnız yapılandırma dosyasını değiştirip yeniden başlatmak veri kaybına yol açabilir. Belgenin önerdiği güvenli sıra şöyledir:

• En güncel dump.rdb dosyasının yedeğini alın ve güvenli bir yere taşıyın.
• Çalışan sunucuda AOF'yi komutla açın: redis-cli config set appendonly yes.
• İsterseniz RDB'yi kapatın: redis-cli config set save "".
• Yazmaların AOF'ye gerçekten eklendiğini doğrulayın.
• Yapılandırma dosyasını güncelleyin; CONFIG REWRITE bunun için kullanılabilir. Bu adım atlanırsa sunucu yeniden başladığında eski yapılandırmayla açılır ve geçiş geri alınmış olur.
• Yeniden başlatmadan önce AOF yeniden yazımının bitmesini bekleyin: INFO persistence çıktısında aof_rewrite_in_progress ve aof_rewrite_scheduled alanlarının kapalı, aof_last_bgrewrite_status alanının ok olduğunu görün.
• Yeniden başlattıktan sonra anahtar sayısının öncekiyle aynı olduğunu doğrulayın.

Bu sıra, yeniden yazım bitmeden sunucuyu yeniden başlatmanın veri kaybı riski taşımasına dayanır. Acele etmeyin, geçişi düşük trafikli bir pencerede yapın.

Yedekleme düzeni kurma

Belge yedeklemeyi vurgulu biçimde ister: yedek yoksa veri kaybı ihtimali büyüktür. RDB dosyaları yedek için idealdir, çünkü bir kez üretildikten sonra değişmez ve çalışan sunucudan güvenle kopyalanır.

Belgenin önerdiği düzen şudur: sunucuda bir cron işi saatlik anlık görüntüleri bir dizine, günlük anlık görüntüleri başka bir dizine kopyalasın. Her çalışmada find komutuyla eski kopyalar silinsin; saatlik kopyalar kısa, günlük kopyalar daha uzun süre tutulsun. Dosyaları tarih ve saatle adlandırın. Günde en az bir kez bir anlık görüntü veri merkezinin ya da en azından makinenin dışına taşınsın.

Dışarı taşıma için nesne depolama servisleri ya da uzak bir sunucuya SCP ile aktarım kullanılabilir. Belge, aktarımdan önce şifrelemeyi (örneğin gpg -c) ve parolayı birden çok güvenli yerde saklamayı önerir. En az, aktarım bitince dosya boyutunu ve mümkünse özet değerini doğrulayın, aktarım durursa uyaracak bağımsız bir izleme kurun.

Yalnız AOF kullanıyorsanız yedek yine alınabilir ama dikkat gerekir. Güncel sürümlerde AOF dizinini kopyalayacaksanız yeniden yazım sırasında kopyalama geçersiz yedek verebilir. Belgenin yolu: otomatik yeniden yazımı geçici olarak kapatın (auto-aof-rewrite-percentage ayarını kapatan değerle), INFO persistence'ta aof_rewrite_in_progress alanının kapalı olduğunu doğrulayın, appenddirname dizinindeki dosyaları kopyalayın, sonra ayarı eski değerine döndürün. Kapalı kalma süresini kısaltmak için dosyalara sabit bağlantı (hard link) oluşturup kopyalamayı bağlantılardan yapabilirsiniz.

Arıza ve geri yükleme: bozuk AOF, doğrulanmış yedek

Sunucu AOF yazarken çökerse dosya sonu eksik bir komutla bitebilir. Belgeye göre güncel Redis sürümleri çoğu zaman bu son bozuk komutu atıp dosyayı yine de yükler ve günlüğe "short read" uyarısı yazar; aof-load-truncated ayarı bunu denetler. Eski sürümlerde ya da dosya ortasında bozulma varsa Redis açılışta durur ve redis-check-aof aracını önerir.

Önce AOF dosyasının yedeğini alın. Sonra redis-check-aof aracını önce --fix bayrağı olmadan çalıştırıp sorunun konumunu görün. Onarım elle mümkündür, çünkü AOF Redis protokolüyle aynı biçimdedir. Aracın --fix modu, bozuk noktadan dosya sonuna kadar olan kısmı atabilir; bozulma dosyanın başındaysa büyük bir kayıp yaşanır. Bu yüzden önce analiz, sonra onarım.

Yedeğin işe yaradığını anlamanın tek yolu geri yüklemeyi denemektir. Düzenli aralıklarla yedeği ayrı bir örneğe yükleyin, anahtar sayısını ve birkaç örnek kaydı kaynakla karşılaştırın. Geri yükleme süresini ölçmek de felaket planının parçasıdır: veri büyüdükçe RDB yüklemesi dakikalar sürebilir ve bu süre kesinti penceresine eklenir.

Yaygın hatalar: save satırlarını silip başka bir yedek mekanizması kurmamak, AOF'yi açıp appendfsync politikasını hiç sorgulamamak, yedeği yalnızca aynı diskte tutmak, RDB dosyasının bütünlüğünü ve boyutunu doğrulamamak ve yapılandırmayı CONFIG SET ile değiştirip dosyaya yazmayı unutmak.