Redis Yedek Alma: SAVE, BGSAVE, redis-cli --rdb ve BACKUP

SAVE: eşzamanlı ve engelleyen anlık görüntü

SAVE veri kümesinin belirli bir andaki anlık görüntüsünü RDB dosyası olarak eşzamanlı üretir. Eşzamanlı olması, kayıt bitene kadar diğer tüm istemcilerin beklemesi demektir. Belge bu yüzden üretim ortamında SAVE komutunu neredeyse hiç istemeyeceğinizi, bunun yerine BGSAVE kullanıldığını söyler.

SAVE komutunun yeri bir son çaredir: fork(2) sistem çağrısındaki hatalar gibi nedenlerle Redis arka plan kaydı için alt süreç oluşturamıyorsa, en güncel veri kümesinin dökümünü almak için SAVE iyi bir seçenek olabilir. Komut başarıda OK döndürür.

BGSAVE: arka planda kayıt

BGSAVE çağrıldığında Redis fork eder: üst süreç istemcilere hizmet vermeye devam eder, alt süreç veritabanını diske kaydeder ve çıkar. Normal durumda yanıt hemen döner; belgeye göre yanıt metni Background saving started şeklindedir. Bu yanıt kaydın başladığını söyler, bittiğini değil.

Zaten çalışan bir arka plan kaydı varsa ya da arka plan kaydı olmayan başka bir süreç, özellikle devam eden bir AOF yeniden yazımı varsa BGSAVE hata döndürür. BGSAVE SCHEDULE biçimi bu durumda hata yerine hemen OK döndürür ve kaydı ilk uygun fırsatta çalışacak şekilde planlar; dönüş bilgisinde bu yanıt Background saving scheduled olarak geçer.

BGSAVE
BGSAVE SCHEDULE
LASTSAVE

İşlemin başarıyla bitip bitmediğini anlamanın belgede tarif edilen yolu LASTSAVE komutudur. LASTSAVE son başarılı kaydın UNIX zamanını tamsayı olarak döndürür. Önce LASTSAVE değerini okur, sonra BGSAVE gönderir, ardından birkaç saniyede bir LASTSAVE değerinin değişip değişmediğine bakarsınız. Belge ayrıca Redis'in başlangıçta veritabanını başarıyla kaydedilmiş saydığını belirtir; yani sunucu yeni başladıysa LASTSAVE başlangıç zamanını gösterebilir.

BGREWRITEAOF: AOF dosyasını küçültmek

Append-only file (AOF) kullanıyorsanız BGREWRITEAOF komutu, mevcut AOF'nin küçük ve iyileştirilmiş bir sürümünü oluşturan yeniden yazma sürecini başlatır. Yeniden yazma başarısız olursa veri kaybolmaz, çünkü eski AOF'ye dokunulmaz. Redis 2.4'ten beri AOF yeniden yazımı otomatik tetiklenir; bu komut onu istediğiniz an başlatmanızı sağlar.

Belge zamanlama kurallarını şöyle sıralar. Bir alt süreç diske anlık görüntü yazıyorsa AOF yeniden yazımı hemen başlatılmaz, RDB kaydı bitene kadar bekleyecek şekilde planlanır; komut yine olumlu bir yanıt döner, yalnızca mesajı farklıdır ve planlandığını INFO içindeki aof_rewrite_scheduled alanından görebilirsiniz. Zaten bir AOF yeniden yazımı sürüyorsa komut hata döndürür ve sonrası için bir şey planlanmaz. Yeniden yazma başlayabilecek durumdayken alt süreç oluşturma gibi bir adım başarısız olursa çağırana hata döner.

INFO persistence ile yedeğin durumunu okumak

Yedekleme betiklerinin ve izleme sistemlerinin dayanması gereken yer INFO persistence bölümüdür. Komutun yanıtı her sürümde aynı alanları içermeyebilir; belge, bilinmeyen alanları atlayan ve eksik alanları sorunsuz karşılayan bir ayrıştırma önerir. Yedekle ilgili başlıca alanlar şunlardır:

Bir yedekleme betiğinde en önemli iki alan rdb_last_bgsave_status ve rdb_last_save_time değerleridir: biri son kaydın başarılı olduğunu, diğeri ne zaman olduğunu söyler. rdb_changes_since_last_save ise son kayıttan bu yana ne kadar verinin yalnızca bellekte olduğunu gösterir; yüksek bir değer, bir çökme durumunda kaybedilecek değişiklik miktarının büyük olduğu anlamına gelir.

RDB dosyasının yazıldığı veri dizinini CONFIG GET dir ile öğrenebilirsiniz; MISCONF hata sayfası disk dolu olduğunda bu dizini bulmak için aynı komutu önerir. CONFIG komutunun ayrıntıları CONFIG GET, SET ve REWRITE yazısında.

Kayıt başarısız olursa: MISCONF

Redis diske kayıt yapamadığında, fark etmeniz için veriyi değiştiren komutları reddetmeye başlayabilir ve MISCONF hatası döndürür; okuma komutları çalışmaya devam eder. Belge yaygın nedenleri disk dolması, Redis'i çalıştıran kullanıcının veri dizinine yazamaması ve düşük bellekte fork() başarısızlığı olarak sayar. Anlık görüntü sorununu giderdikten sonra BGSAVE başarılı olduğunda Redis yazmaları yeniden kabul eder. Hatanın tam metni, çözüm adımları ve stop-writes-on-bgsave-error ayarının etkisi OOM, MISCONF ve READONLY hataları yazısında anlatılıyor.

redis-cli --rdb ile uzaktan RDB yedeği

Replikasyonun ilk eşitlemesinde birincil ve replika tüm veri kümesini RDB dosyası olarak değiş tokuş eder. redis-cli bu özelliği kullanarak herhangi bir Redis örneğinden, redis-cli'nin çalıştığı yerel bilgisayara RDB dosyası aktarmanızı sağlar. Belge bunu felaket kurtarma için RDB yedeklerinin var olmasını sağlamanın basit ama etkili bir yolu olarak tanıtır.

$ redis-cli --rdb /tmp/dump.rdb
SYNC sent to master, writing 13256 bytes to '/tmp/dump.rdb'
Transfer finished with success.

Bu seçeneği betiklerde ya da cron görevlerinde kullanırken komutun dönüş değerini mutlaka kontrol edin. Belgedeki hata örneğinde aktarım başarısız olur ve çıkış kodu sıfırdan farklıdır:

$ redis-cli --rdb /tmp/dump.rdb
SYNC with master failed: -ERR Can't SYNC while not connected with my master
$ echo $?
1

Uzaktan yedek, sunucunun kendi diskinde ayrı bir kopya tutmak yerine dosyayı doğrudan yedek makinesine getirdiği için, sunucunun diski arızalandığında da işe yarar. Bağlantı seçenekleri (-h, -p, --user, TLS) normal redis-cli kullanımıyla aynıdır; ayrıntılar redis-cli kullanımı yazısında. Yedeği alan kullanıcının ACL kuralları bu işlemi yapmaya izin vermelidir; kural sözdizimi ACL yazısında.

Uygulamalı örnek: gece yedeği betiği

Aşağıdaki betik belgelerdeki redis-cli davranışına göre yazılmış kendi örneğimizdir. Uzaktan RDB yedeğini tarihli bir dosyaya alır, dönüş kodunu kontrol eder ve hata durumunda betiği başarısız sonlandırır. Şifre, belgenin önerdiği gibi REDISCLI_AUTH ortam değişkeniyle verilir.

#!/usr/bin/env bash
set -u
HEDEF="/yedek/redis/dump-$(date +%F).rdb"
export REDISCLI_AUTH="$REDIS_YEDEK_SIFRE"

if ! redis-cli -h 10.0.0.5 -p 6379 --user yedek --rdb "$HEDEF"; then
  echo "Redis yedegi alinamadi" >&2
  exit 1
fi

redis-cli -h 10.0.0.5 -p 6379 --user yedek INFO persistence | grep -E "rdb_last_bgsave_status|rdb_last_save_time"

Betikte if ! yapısı, belgede gösterilen sıfırdan farklı çıkış kodunu yakalar. Son satır sunucunun kendi yerel kaydının durumunu da raporlar; uzaktan yedek ile sunucudaki RDB kaydı farklı mekanizmalardır, ikisini birlikte izlemek iyi bir alışkanlıktır. Yedek dosyalarının kaç gün saklanacağı, şifrelenmesi ve geri yükleme testleri için yedekleme stratejileri yazısına bakın.

BACKUP komut ailesi (Redis 8.10)

Redis 8.10 sürüm notlarına göre yeni BACKUP komutu, çok parçalı AOF (MP-AOF) üzerine kurulu, düğüm tarafında çalışan bir yedekleme ve geri yükleme altyapısı ekler. Bu komutlar 8.10 öncesi sürümlerde yoktur. Aile, bir durum makinesi etrafında çalışır ve BACKUP STATUS bu makinenin o anki durumunu bildirir:

Akış şöyledir. BACKUP START durumu idle konumundan snapshotting konumuna geçirir ve AOF yeniden yazımı yoluyla yeni bir BASE anlık görüntüsü üretmeye başlar. AOF açıksa mevcut çok parçalı AOF doğrudan kullanılır; kapalıysa Redis, yapılandırılmış appendonly değerini değiştirmeden AOF altyapısını geçici olarak başlatır. Başka bir alt süreç çalışıyorsa yedek pending durumuna girer. Anlık görüntü bitince BASE dosyası yedek dizinine sabit bağlantı (hard link) ile bağlanır ve durum incrementing olur.

> BACKUP START
OK
> BACKUP LIST
1) "/var/lib/redis/backupdir/appendonly.aof.3.base.rdb"
> BACKUP SEAL
OK
> BACKUP LIST
1) "/var/lib/redis/backupdir/appendonly.aof.3.base.rdb"
2) "/var/lib/redis/backupdir/appendonly.aof.3.incr.aof"
3) "/var/lib/redis/backupdir/appendonly.aof.manifest"
> BACKUP CLEANUP
OK

Yukarıdaki komutlar ve yanıtlar ilgili komut sayfalarındaki örneklerden bir araya getirilmiştir. BACKUP LIST, o ana kadar sabitlenmiş değişmez dosyaların mutlak yollarını verir; incrementing durumundayken yalnızca BASE dosyası listededir, bu da BASE dosyasını yedek sealed olmadan kopyalamaya başlayabilmenizi sağlar. BACKUP SEAL durumu sealed yapar: geçerli INCR dosyasını diske yazıp eşitler, onu yedek dizinine bağlar, yalnızca bu yedeğin BASE ve INCR dosyalarına başvuran bağımsız bir manifest yazar, AOF açıksa canlı AOF'yi döndürür. Geri yükleme BASE ile INCR dosyalarını birlikte yüklediği için geri yüklenen veri, mühürleme anındaki durumu yansıtır.

Dosyalar kopyalandıktan sonra BACKUP CLEANUP mühürlenmiş (ya da başarısız) yedeğin dosyalarını kaldırır, sabit bağlantılarla tutulan dosyaları serbest bırakır ve durumu idle konumuna döndürür. backup-sealed-ttl ayarı sıfırdan farklıysa mühürlenmiş yedek bu kadar saniye sonra otomatik temizlenir; 0 otomatik temizliği kapatır. Mühürlenmemiş bir yedeği iptal etmek için BACKUP ABORT kullanılır; durum failed olur ve yeni bir yedek başlatılabilir.

> BACKUP STATUS
1) "state"
2) "incrementing"
3) "error"
4) ""
5) "start_time"
6) "1717921800"
7) "end_time"
8) "0"

İki kısıtı unutmayın: backupdirname ayarıyla adlandırılan ve Redis çalışma dizini dir altında çözümlenen yedek dizini BACKUP START çağrıldığında boş olmalıdır, ve aynı anda yalnızca bir yedek sürebilir. Hafif izleme için INFO persistence bir backup_in_progress mantıksal alanı sunar; durum, hata ve zaman bilgisinin tamamı ise yalnızca BACKUP STATUS ile alınır. Geri yükleme yordamının ayrıntısı resmî belgelerin yönetim bölümündeki kalıcılık sayfasındadır ve bu yazının kaynağı olan belgelerin dışında kalır.

Hangi yöntem ne zaman

Sık yapılan hatalar

• BGSAVE yanıtını yedeğin tamamlandığı sanmak: yanıt yalnızca alt sürecin başladığını bildirir; bitişi LASTSAVE ya da INFO persistence ile doğrulayın.
• Canlı sunucuda SAVE çalıştırmak: kayıt bitene kadar tüm istemciler bekler.
• Betikte redis-cli --rdb çıkış kodunu kontrol etmemek: aktarım başarısız olsa bile cron görevi sessizce "başarılı" görünür.
• Yedeği yalnızca aynı sunucunun diskinde tutmak: disk arızasında hem veri hem yedek kaybolur; uzaktan yedek ya da dosyanın kopyalanması gerekir.
• Fork sırasında artan belleği hesaba katmamak: yoğun yazma altında copy-on-write belleği büyür; rdb_last_cow_size değerini izleyin.
• BACKUP START öncesi yedek dizinini boşaltmamak ya da mühürlenen yedeği kopyaladıktan sonra BACKUP CLEANUP çağırmayı unutmak: bir sonraki yedek başlatılamaz.

Sık Sorulan Sorular

BGSAVE Background saving started dediğinde yedek alınmış olur mu?

Hayır. Bu yanıt yalnızca alt sürecin başladığını söyler. Yedeğin bittiğini LASTSAVE değerinin değişmesinden ya da INFO persistence içinde rdb_bgsave_in_progress değerinin sıfıra dönmesinden ve rdb_last_bgsave_status değerinin err olmamasından anlarsınız. MISCONF hata sayfası, rdb_last_bgsave_status:err satırını son anlık görüntünün başarısız olduğunun işareti olarak gösterir.

BGSAVE neden hata veriyor?

Belgeye göre zaten bir arka plan kaydı ya da AOF yeniden yazımı sürüyorsa hata döner. Beklemek istemiyorsanız BGSAVE SCHEDULE kullanın; kayıt ilk uygun fırsatta başlar.

SAVE ile BGSAVE arasındaki fark nedir?

SAVE kaydı ana süreçte yapar ve bitene kadar tüm istemcileri bekletir. BGSAVE fork eder; kaydı alt süreç yapar, ana süreç hizmete devam eder.

BACKUP komutu eski sürümlerde var mı?

Hayır, BACKUP ailesi Redis 8.10 ile geldi. Daha eski sunucularda BGSAVE ve redis-cli --rdb kullanın; sürümü INFO server içindeki redis_version alanından kontrol edin.

redis-cli --rdb başarısız olduğunda nasıl anlarım?

Komutun çıkış kodu sıfırdan farklı olur ve ekrana nedenini yazar. Betiklerde bu kodu mutlaka kontrol edin; belge bu noktayı özellikle vurgular.

Marka adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen kuruluşlarla bayilik veya ortaklık ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: Redis öğrenme rehberi · Veritabanı yedekleme stratejileri · Redis nedir · OOM, MISCONF ve READONLY hataları · INFO komutu ve sunucu izleme