MagicMirror Projesi: SQLite hafızası ve tutarlı yedekleme

MagicMirror Projesi’nin kişisel hafızasını SQLite üzerinde ayrı bir bileşen olarak kurduk. Yedekleme betiğini de çalışan veritabanının ana dosyasını gelişigüzel kopyalamak yerine veritabanı destekli tutarlı kopya üretecek şekilde düzenledik. Burada gerçek hafıza kayıtları ve özel yedek konumları gösterilmiyor; anlatım sürümlü kodda bulunan işleyişe dayanıyor.

Projede yaptığımız düzenleme

Yedek hattında hedef depolamanın bağlı olup olmadığını kontrol eden bir başlangıç koşulu, geçici hazırlama dizini ve tamamlanma sonrası dosya geçişi bulunuyor. Veritabanı kopyası Node.js SQLite yedekleme arayüzüyle oluşturuluyor; ardından salt okunur bağlantıyla quick_check sonucu denetleniyor. Bu hızlı kontrolü SQLite’ın daha kapsamlı bütünlük denetimi veya uygulama düzeyinde geri dönüş testiyle aynı kabul etmiyoruz.

Arşiv oluşturulduktan sonra SHA-256 doğrulaması ve arşivin okunabilirlik kontrolü yapacak adımlar ekledik. İşletim kaydında tamamlanmış ve yarım kalmış arşivler ayrı tutuluyor; kısmi dosya sağlam yedek sayılmıyor. Yüz verisi, özel not, hesap ayarı ve gerçek dosya yolları bu yazıya taşınmadı. Aşağıdaki kabul planı, kaynakta bulunan bu hattın hangi farklı kanıtlarla değerlendirilmesi gerektiğini açıklıyor.

WAL açıkken tek dosya bütün durum değildir

SQLite WAL kipinde tamamlanmış işlemler bir süre ana veritabanına aktarılmadan yazma günlüğünde bulunabilir. Bu yüzden çalışan uygulamanın yalnızca ana veritabanı dosyasını sıradan dosya kopyasıyla almak güncel ve tutarlı bir yedek oluşturduğunuzu göstermez. Günlük dosyasını silmek veya rastgele zamanlarda ayrı ayrı kopyalamak da genel çözüm değildir. Bağlantıların ve yazma işlemlerinin durumu yedek yönteminin parçasıdır.

SQLite'ın çevrimiçi yedekleme arayüzü, kaynak veritabanından hedef veritabanına tutarlı bir görüntü oluşturmak için tasarlanmıştır. Kullanılan dil bağlayıcısında bu arayüzün nasıl sunulduğunu ve hangi hata durumlarını bildirdiğini kontrol edin. Bu yazı kurulu bağlayıcının sürümünü varsaymaz. Hedef dosya üretilemediğinde önceki sağlam yedeğin üzerine bozuk veya boş bir dosya geçirilmemelidir.

1. Yazma ve sürümü belirle
2. Tutarlı kopya oluştur
3. Kopyanın bütünlüğünü sına
4. Yalıtılmış uygulamada aç
5. Kapsamı ve saklamayı kabul et

Kopya üretimini bir işlem olarak tasarlayın

Her çalıştırmada yeni ve benzersiz bir geçici hedef kullanın. Kaynak bağlantı, hedef yol, sonuç kodu ve bitiş zamanı açıkça belli olsun. Hedef dosyayı yalnızca yedekleme işlemi başarıyla tamamlandıktan ve doğrulandıktan sonra kullanılabilir olarak işaretleyin. Disk dolması, izin hatası ve kilit beklemesi için ayrı sonuçlar üretin. Tek bir dosyanın varlığı başarılı yedek anlamına gelmez.

Yoğun yazma sırasında yöntemin gecikmesini ölçmek gerekir. Sınırsız yeniden deneme, hem uygulamayı hem yedek hattını sıkıştırabilir. Deneme sayısına, bekleme süresine ve toplam çalışma zamanına sınır koyun. Başarısız çalıştırmayı gizlemek için zorla checkpoint veya dosya silme uygulamayın. WAL davranışı ve bağlayıcı desteği kurulu sürümün belgesiyle birlikte değerlendirilmelidir; genel bir performans kazanımı iddia edilmemelidir.

Dosya bütünlüğü ile hafıza doğruluğunu ayırın

Kopyayı bağımsız bir bağlantıyla açıp uygun SQLite bütünlük denetimini yürütün. Bütünlük denetiminin olumlu sonucu, uygulamanın beklediği bütün hatırlatıcıların kopyada bulunduğunu tek başına kanıtlamaz. Yalnızca sentetik laboratuvar kayıtlarıyla bilinen birkaç olayı, profil ayrımını ve zaman bilgisini ayrıca doğrulayın. Şema sürümüyle uygulama sürümü uyumlu olmalıdır; otomatik göçün eski yedeği değiştirmesine dikkat edin.

Dosyanın SHA-256 özeti aktarım sırasında aynı baytların korunup korunmadığını denetlemeye yardımcı olur. Bununla birlikte hash değeri verinin güncel, eksiksiz veya yetkisiz erişimden korunmuş olduğunu kanıtlamaz. Şifreleme, erişim yetkisi ve anahtar kurtarma yolu başka kontrollerdir. Yayınlanan kanıta gerçek kişi adını, not metnini, veritabanı içeriğini veya özel dosya konumunu eklemeyin.

Geri yüklemeyi canlı hafızadan uzakta deneyin

Yedek denemesi için ayrı bir dizin ve dış araçları kapalı bir uygulama örneği hazırlayın. Hatırlatıcıların gerçek bildirim üretmesini veya test örneğinin gerçek hesaplarla iletişim kurmasını önleyin. Kaynağa yazma yapılmadığını, sentetik kayıtların okunabildiğini ve uygulamanın beklenen biçimde kapandığını kontrol edin. Geri yükleme sırasında oluşturulan geçici kopyanın saklama süresini de belirleyin.

Gerçek geri dönüş gerektiğinde önce hizmetin yazma davranışını kontrollü biçimde durdurun, mevcut durumu koruyun ve seçilen yedeğin tarihini teyit edin. Geri dönüş sonrasında oluşacak veri kaybı aralığı açıkça belirtilmelidir. Eski yedeğe dönmek o arada eklenen kayıtları otomatik birleştirmez. Geri dönüşün ardından kişisel veri içermeyen uygulama kabulü yapılmadan sistemi sağlıklı ilan etmeyin.

Saklama ve kapsam

Bir hafıza kaydı canlı sistemden silindiğinde eski yedeklerde bulunmaya devam edebilir. Saklama politikası, erişim sınırı ve yedeklerin zamanında kaldırılması bu nedenle tasarımın parçasıdır. Bu rehberde yedek veya geri yükleme işleminin başarıyla yürütüldüğü iddia edilmiyor. Değerli kanıt, dosya sayısı değil tarihli bir doğrulama kaydı ve gerçekten çalıştırılmış yalıtılmış geri dönüş senaryosudur.

Serinin bütün çalışmaları: MagicMirror Projesi.

Nasıl yapılır: ayrıntılı uygulama

Ortam ve ön koşullar: SQLite CLI ile tutarlı kopya örneği — SQLite CLI ve mevcut kaynak DB gerekir; hedef adını önceki yedeği ezmeyecek şekilde seçin.

1. Kaynak DB ve WAL durumunu okuyun
2. Güvenli ve benzersiz backup hedefi seçin
3. Kopyanın bütünlüğünü ve manifest’ini ölçün
4. Restore’u önce izole yeni DB yolunda sınayın
5. Canlı geri dönüş planını kapatın

1. Kaynak DB ve WAL durumunu okuyun

SQLite CLI kurulu, izinli uygulama kullanıcısı ve mevcut DB dosyası gerekir. Önce .open yanlış yolda boş DB oluşturmasın diye dosyanın varlığını doğrulayın. Gerçek hafıza içeriği sorgulanmaz.

test -f /GERCEK/VERI/YOLU/memory.sqlite
sqlite3 -readonly /GERCEK/VERI/YOLU/memory.sqlite "PRAGMA journal_mode; PRAGMA quick_check;"

2. Güvenli ve benzersiz backup hedefi seçin

DB ana dosyasını WAL/SHM’den kopuk cp ile yedeklemeyin. Özel hedef, uygulama yetkisi ve yeterli alan gerekir. Aşağıdaki script mevcut backup’ı ezmez; başarısız backup kullanılmaz.

umask 077
source_db=/GERCEK/VERI/YOLU/memory.sqlite
backup_db=/OZEL/YEDEK/YOLU/batuhanyazici-memory-kabul.sqlite
if [ ! -f "$source_db" ] || [ -e "$backup_db" ]; then
  printf 'Kaynak veya benzersiz hedef kosulu saglanmadi
' >&2
else
  sqlite3 -readonly "$source_db" ".timeout 5000" ".backup '$backup_db'" &&
  sqlite3 -readonly "$backup_db" 'PRAGMA integrity_check;'
fi

3. Kopyanın bütünlüğünü ve manifest’ini ölçün

integrity_check sonucu ok olmalı; tablo içeriğini public loga basmayın. Dosya hash’i taşımada bütünlüğü kontrol eder, doğru uygulama şemasının yerine geçmez.

sqlite3 -readonly /OZEL/YEDEK/YOLU/batuhanyazici-memory-kabul.sqlite "PRAGMA integrity_check; PRAGMA user_version;"
sha256sum /OZEL/YEDEK/YOLU/batuhanyazici-memory-kabul.sqlite

4. Restore’u önce izole yeni DB yolunda sınayın

Gerçek uygulama kopyasını kapatın, backup’ı onun yeni DB yoluna yetkili dosya sahibini koruyarak alın. Uygulama sürümü/schema uyumu, sentetik yeni kayıt ve yeniden açılışta kalıcılığı kontrol edin. Canlı DB’nin üstüne çalışan süreç varken yazmayın.

5. Canlı geri dönüş planını kapatın

Gerekli bakımda writer’ları durdurup mevcut DB/WAL/SHM takımını korunmuş özel konuma ayırın; desteklenen restore yordamıyla tutarlı backup’ı kullanın. Stale WAL dosyasını yeni DB’ye eşlemeyin; başarısızlıkta uyumlu eski takıma planlı dönün. Özel hafıza verisi yayımlanmaz.

Beklenen sonuç: Sağlam kopyada quick_check sonucu ok olur; gerçek kayıt doğruluğu ayrıca sınanır.

Sonuç farklıysa: Kaynak yol yanlışsa -readonly açılışını düzeltin; boş yeni DB oluşturup yedek başarılı sanmayın.

Geri dönüş: Doğrulanmış uyumlu kopyayı uygulamanın desteklenen geri kurulum yoluyla kullanın.