Azure SQL'de sabit zamanlı kurtarma: rollback artık saatler sürmüyor
Microsoft, Azure SQL Database'de büyük bir işlem çöktüğünde veritabanını saatlerce kilitleyen geri alma (undo) sürecini sabit süreye indiren Constant Time Recovery yaklaşımını anlatıyor. Kalıcı sürüm deposu ve mantıksal geri alma sayesinde kurtarma süresi, işlemin dokunduğu satır sayısından bağımsız hale geliyor. Özellik bugün Accelerated Database Recovery adıyla Azure SQL'de zorunlu, SQL Server'da ise isteğe bağlı olarak açılabiliyor.
Kilit noktalar
- Kurtarma ve rollback süresi artık işlemin büyüklüğüne bağlı değil; 99,999. persentilde bir saat üzeri süre 3 dakikaya indi.
- Kalıcı sürüm deposu (PVS) satır sürümlerini veritabanında tutuyor; küçük değişiklikler satır içi byte diff, büyükler off-row tablo olarak saklanıyor.
- Abort, bellekteki Aborted Transaction Map üzerinden anlık işaretleniyor; eski sürümler arka planda temizleniyor.
- 50 milyon satırlık delete'te log kullanımı 38 GB'tan 147 MB'a, 10 milyon insert'te 5.101 MB'tan 99 MB'a düştü.
- ADR, Azure SQL Database'de her zaman açık ve kapatılamıyor; SQL Server'da mevcut ama varsayılan olarak kapalı.
- SQL Server 2022 çok iş parçacıklı temizlik getirdi, SQL Server 2025 ise ADR'yi tempdb'ye genişletiyor.
Klasik ARIES algoritması üç aşamada çalışır ve son aşamadaki undo işlemi, işlemin yaptığı iş kadar maliyetlidir: 50 milyon satıra dokunan bir transaction, 50 milyon birim geri alma demek. VLDB 2019'da yayımlanan çalışmada ekip, snapshot isolation için kullanılan sürüm deposunu kalıcı hale getiriyor. Satır sürümleri veritabanının kendisinde tutuluyor; küçük değişiklikler satır içinde byte diff, büyükleri ayrı bir tabloda saklanıyor.
Böylece abort anında log geri sarılmıyor: işlem kimliği bellekteki Aborted Transaction Map içinde işaretleniyor, sorgular o sürümü atlayıp öncekini okuyor ve temizlik arka planda yapılıyor. Sürümlenemeyen az sayıdaki işlem için küçük bir SLog akışı var. Üretim verilerinde 99,999. persentil kurtarma süresi bir saatten 3 dakikaya iniyor; 50 milyon satırlık delete'in log kullanımı 38 GB yerine 147 MB oluyor. Bedeli, güncelleme ağırlıklı TPC-C yükünde %13,8'e varan throughput düşüşü.
Gerçek dünyada kullanımı
- .NET servisinde milyonlarca satırlık toplu veri yüklemesi yapan bir import job'ı, yükleme ortasında sunucu yeniden başladığında tabloların saatlerce kilitli kalmasını istemez.
- Hatalı çalışan uzun bir UPDATE'i iptal eden bir operatör, rollback'in güncelleme kadar uzun sürmesini beklemeden sistemi normale döndürmek ister.
- Gece bakım penceresinde büyük silme işlemleri çalıştıran bir ekip, transaction log'un şişip uygulamayı durdurmasını engellemek ister.
- Failover sonrası kurtarma süresini SLA'ya sığdırması gereken çok kiracılı bir SaaS veritabanı, öngörülebilir açılış süresi hedefler.
Neden önemli
Uygulamanızın en kötü senaryosu artık veritabanı boyutuna değil, sabit bir süreye bağlı: büyük işlemler iptal edilebilir hale geliyor ve bakım ya da failover sonrası kesinti öngörülebilir oluyor.