Accelerated Database Recovery: Kurtarmayı Sabitleyen Yapı

Tek bir transaction içinde birkaç yüz milyon satır yükleniyor, işlemin tam ortasında sunucu beklenmedik şekilde yeniden başlıyor. Klasik kurtarma mantığında SQL Server ayağa kalktığında o transaction’ın yaptığı her şeyi log üzerinden geriye doğru yürüyerek satır satır geri almak zorunda, bu bitene kadar da ilgili tablolara kimse dokunamıyor. Constant Time Recovery (CTR), ürün adıyla Accelerated Database Recovery (ADR), tam da bu bağımlılığı kırmak için tasarlandı; kurtarma süresi artık iptal edilen işin büyüklüğüne orantılı değil.

Bu yazı, Azure SQL ekibinin VLDB 2019’da yayımladığı Constant Time Recovery in Azure SQL Database makalesine ve Anna Hoffman’ın bu makaleyi ele alan blog yazısına dayanıyor.

Sorun ARIES’in undo fazında

Veritabanları 90’ların başından beri ARIES (Algorithms for Recovery and Isolation Exploiting Semantics) adlı kurtarma algoritmasını kullanıyor. ARIES üç fazda çalışır: analysis, redo ve undo. Darboğaz undo fazında. Makalenin ifadesiyle, veritabanını tutarlı bir duruma getirmek commit edilmemiş transaction’ların yaptığı tüm işlemlerin geri alınmasını gerektirir; bu da kurtarma maliyetini bu transaction’ların yaptığı işle orantılı hale getirir.

50 milyon satıra dokunan bir transaction, 50 milyon birimlik undo üretir. 1995’in departman sunucusunda transaction’lar küçüktü, maliyet de kabul edilebilir bir seviyedeydi. Milyonlarca veritabanı barındıran, donanım arızalarının ve bakım kaynaklı yeniden başlatmaların rutin olduğu bir bulut servisinde ise aynı orantılılık doğrudan bir erişilebilirlik sorununa dönüşüyor.

Makalenin açılışındaki örnek bunu somutlaştırıyor: bir Azure SQL müşterisi tek transaction içinde yüz milyonlarca satır yüklerken beklenmedik bir arıza yaşanmış, veritabanının kurtarılması 12 saat sürmüş ve bu süre boyunca ilgili tablolara tamamen erişilememiş.

Geri almak yerine yok saymak

SQL Server’da snapshot isolation için zaten bir version store vardı: bir satır güncellendiğinde eski sürümü tempdb’de tutuluyor, okuyucular tutarlı bir görüntü görüyordu. CTR bu fikri kalıcı hale getiriyor.

Persistent Version Store (PVS)

Satır sürümleri artık tempdb’de değil, veritabanının kendi içinde tutuluyor; yani yeniden başlatmayı atlatıyorlar. Küçük değişiklikler satır içinde (in-row), mevcut satırın yanında bir byte diff olarak saklanıyor, daha büyük olanlar satır dışı (off-row) bir tabloya gidiyor.

Logical revert

Esas kazanç burada. Bir transaction abort olduğunda sistem log’u gezip değişiklikleri geri almıyor; bunun yerine Aborted Transaction Map adı verilen bellek içi bir hash tablosunda ilgili transaction ID’yi “abort edilmiş” olarak işaretliyor. Sonradan gelen herhangi bir sorgu, o transaction’ın yazdığı bir satır sürümüyle karşılaştığında onu atlıyor, bir önceki sürümü okuyor. Abort işlemi pratikte anlık tamamlanıyor, temizlik ise arka planda tembel (lazy) biçimde yapılıyor. Makalenin ifadesiyle: satır sürümleri arka planda tembel şekilde temizlenirken veritabanı tüm kilitleri serbest bırakarak tamamen erişilebilir kalıyor.

SLog

Her işlem sürümlenemiyor. Belirli metadata değişiklikleri ve kilit edinimleri gibi az sayıdaki işlem, küçük bir ikincil log akışına (SLog) yazılıyor. Sayıları çok az olduğu için bu kayıtlar sabit zamanda redo ve undo edilebiliyor.

Tasarımın en dikkate değer yani, motorun baştan yazılmamış olması. Makaleye göre CTR, geleneksel ARIES ile çok sürümlü eşzamanlılık denetimini (MVCC) birleştirerek depolama motorunu kökten yeniden tasarlamaya gerek kalmadan kurtarma süresini iyileştiriyor.

Ölçülen sonuçlar

Makalede, Azure SQL Database üretim ortamında ölçülen kurtarma süreleri şöyle raporlanıyor:

Yüzdelik	Geleneksel	CTR
99,9	68 sn	60 sn
99,99	10 dakikadan fazla	1,3 dakika
99,999	1 saatten fazla	3 dakika

Ortalamada kayda değer bir fark yok, fark kuyrukta ortaya çıkıyor: 99,999’uncu yüzdelikte bir saati aşan kurtarma süresi üç dakikaya iniyor. Rollback de aynı mekanizmadan faydalanıyor.

İkinci kazanım transaction log tarafında. Abort edilen iş artık undo amacıyla log’da tutulmak zorunda olmadığı için, büyük bir transaction çalışırken bile log agresif biçimde truncate edilebiliyor:

İşlem	Geleneksel log	CTR log
10M insert	5.101 MB	99 MB
50M insert	25.873 MB	185 MB
50M delete	38.255 MB	147 MB

50 milyon satırlık silme işlemi önceden 38 GB log tüketirken CTR ile 147 MB’ta kalıyor. Bir bakım işinin transaction log’u doldurup uygulamayı durdurduğu bir senaryo yaşadıysanız bu satırın anlamı açıktır.

Maliyet tarafı

Bunun bir bedeli de var. Makaledeki ölçümlere göre güncelleme ağırlıklı TPC-C iş yükünde, satır içi sürümleme etkinken throughput %13,8 düşüyor; satır içi sürümleme olmadan bu kayıp %28’e çıkıyor. Daha karma bir profil olan TPC-E’de ise etki %2,4 seviyesinde. Yani ekip, kuyruktaki saatlerce süren kesintileri ortadan kaldırmak karşılığında tek haneli ile düşük çift haneli arasında bir throughput maliyetini kabul etmiş durumda. Bu rakamlar makalenin yazıldığı dönemin ölçümleri.

CTR, Azure SQL Database’de Mayıs 2019’da dünya genelinde üç milyondan fazla veritabanı için etkinleştirildi.

Bugün pratikte ne anlama geliyor?

CTR, ürün tarafında Accelerated Database Recovery adıyla geliyor. Azure SQL Database’de her zaman açık ve kapatılamıyor; SQL Server tarafında 2019 sürümünden itibaren kullanılabilir durumda. Pratik sonuçları:

• Büyük bir transaction’ın rollback’i hızlı, boyuttan bağımsız olarak. Kontrolden çıkmış bir UPDATE’i iptal etmek, artık güncellemenin sürdüğü kadar beklemek anlamına gelmiyor.
• Failover sonrası kurtarma öngörülebilir. Erişilebilirlik SLA’sını anlamlı kılan şey tam olarak bu öngörülebilirlik.
• Uzun süren veri yüklemeleri log’u şişirmiyor.
• Optimized locking buna bağımlı. Azure SQL’de gelen kilit iyileştirmeleri doğrudan bu makalenin tanıttığı persistent version store üzerine kurulu.

Makaleden bu yana değişenler

Takip eden çalışmaların büyük bölümü version store’un kendi ayarlarına odaklandı:

• Temizlik hızlandı. Orijinal tasarım eski satır sürümlerini tek bir arka plan iş parçacığıyla temizliyordu; yoğun sistemlerde bu geride kalabiliyor, version store büyüyebiliyordu. SQL Server 2022 bu temizliği çok iş parçacıklı hale getirdi, yalnızca abort edilmiş değil commit edilmiş transaction’lar için de temizlik ekledi ve arka plan süreci bloklandığında kullanıcı transaction’larının temizliğe yardım etmesine izin verdi. Sürümleri izlemek için kullanılan bellek de azaltıldı.
• tempdb rollback’i aynı muameleyi gördü. SQL Server 2025, ADR’yi tempdb’ye genişletiyor; geçici tabloları içeren büyük bir rollback, o işi üreten işlem kadar uzun sürmüyor artık.
• Bir bağımlılık haline geldi. ADR, Azure SQL Database’de her zaman açık ve artık optimized locking için ön koşul. 2019 tarihli bir kurtarma makalesi, sonraki kilit yeniden tasarımını mümkün kılan temel oldu.

SQL Server’ı kendiniz işletiyorsanız ADR kullanılabilir durumda ama varsayılan olarak kapalı geliyor. Yoğun bir veritabanında etkinleştirmeden önce güncel bir sürümde olmak, version store temizliğindeki iyileştirmeler nedeniyle anlamlı bir tercih.

Neden önemli?

CTR’nin ilgi çekici yani, onlarca yıldır evrim geçirmediği varsayılan bir alanda, yani ilişkisel veritabanı kurtarmasında, üretime çıkmış yeni bir algoritma olması. ARIES 25 yıl boyunca ders kitabı cevabıydı; bu çalışma cevabı değiştirdi, üstelik tek bir uygulamayı bozmadan yaptı bunu. Ekip zarafeti kendi başına bir amaç saymadı: ARIES’in işe yaradığı yeri korudu, sürümlemenin fayda sağladığı yere sürümleme ekledi, uyumsuz kalan az sayıdaki işlemi de küçük bir yan kanala taşıdı.

Makalenin yazarları

Constant Time Recovery in Azure SQL Database; Panagiotis Antonopoulos, Peter Byrne, Wayne Chen, Cristian Diaconu, Raghavendra Thallam Kodandaramaih, Hanuma Kodavalla, Prashanth Purnananda, Adrian-Leonard Radu, Chaitanya Sreenivas Ravella ve Girish Mittur Venkataramanappa (Microsoft) tarafından yazıldı.

Kaynaklar ve İleri Okuma

• devblogs.microsoft.com

• Anna Hoffman — How Microsoft SQL learned to recover without undoing everything first (Azure SQL Dev Corner)
• Constant Time Recovery in Azure SQL Database (VLDB 2019, PDF)
• Microsoft Learn — Accelerated Database Recovery kavramları
• Microsoft Learn — Accelerated Database Recovery yönetimi ve etkinleştirme
• Azure SQL Dev Corner blogu