Write-Ahead Logging nedir ve RDBMS’ler neden kullanır?
Bu flood’da RDBMS’lerde ACID prensiplerinden A (Atomicity) ve D (Durability)’yi sağlayan Write-Ahead Logging (WAL)’i anlatacağım.
Önceki flood’larda ACID prensiplerinin genel amacına ve kısaca Atomicity, Consistency, Isolation ve Durability özelliklerine değinmiştik.
Veri tabanı yönetim sistemleri, üzerlerinde yapılan değişiklik, yeni kayıt ekleme ve silme işlemlerini, bilgilerin asıl tutulduğu diskteki Data Page’lere yazmanın yanında Transaction Log adı verilen log dosyalarına da yazarlar. Write-Ahead Logging (WAL adı verilen mekanizma ise database'lerde, transaction log dosyası diske yazılmadan Data Page'in diske yazılmayacağını garanti eder. Evet yanlış okumadınız, RDBMS öncelikle transaction log'u diske yazar, sonra da Data Page'i diske yazar.
Şimdi aşağıdaki görselde özetlenen bu mekanizmanın neden var olduğunu anlamaya çalışalım.
RDBMS’ler Transaction’ı başlatan ve commit eden uygulamaya “Başarılı bir şekilde Commit edildi” bilgisini Transcation Log dosyası diske yazıldığında verirler. Data Page’lerin diske yazılmasını beklemezler. Transaction Log’lar ardışıl disk Page’lerinde oldukları için onların diske yazılması muhtemelen dağınık durumda bulunan Data Page’lerin diske yazılmasından daha hızlı olacaktır. Bu anlamda RDBMS’lerin WAL mekanizmasıyla A ve D özelliklerini sunmanın yanı sıra performans artışı sağladığını da söyleyebiliriz. Bazı RDBMS’ler (Postgres, MS-SQL) risk alarak performans için, A ve D’den taviz vermek isteyenlere özel Transcation Log’ların diske yazılma işleminin Asenkron yapılmasına da olanak tanır. Bu durumda RDBMS, Transaction Log’un diske yazılmasını beklemeden Transaction’ın başarılı olduğunu uygulamaya bildirir.
Transaction’ın ortasında sunucunun çökmesi veya elektriğinin kesilmesi durumunu ele alalım. İlk örnekte database Ram’de Transaction Log’a bütün işlemi kaydetmiş, diske Transaction Log’u yazmış ancak Data Page’lere yazamamış olsun. Database yeniden başlatıldığında Transaction Log’u okuyarak aslında tamamlanmış olan Transaction’ın Data Page’lere işlenmediğini anlayacak ve Transaction Log’u tekrar Replay ederek Data Page’lere ilgili data’nın doğru olarak yazılmasını sağlayacaktır. Bu şekilde hem Durability hem de Atomicity’yi sağlamış olacaktır.
İkinci bir örnek olarak yine elektrik kesilmesi sonucu database Ram’de Transaction Log’a bütün işlemi kaydetsin fakat bu Transaction Log’u diske aktarmaya çalışırken işlemin yarısında elektrik kesintisi olsun. Database bu durumda yeniden başlatıldığında Transaction Log’da bir takım işlemlerin başladığını fakat Commit edilmediğini görecek ve bu Transaction’ı yok sayacaktır.
Son olarak Transaction’ın yaşam döngüsünden bağımsız olarak Checkpoint adı verilen mekanizma Transaction Log dosyaları diske yazılmış olan Data Page'leri asenkron olarak diske yazar.
