Durability — transaction muvaffaqiyatli commit deb tasdiqlangach uning natijasi process, operatsion tizim yoki quvvat uzilishidan keyin ham saqlanishini bildiradigan ACID xususiyati. Database clientga muvaffaqiyat javobini berishdan oldin tiklash uchun yetarli ma’lumotni barqaror saqlash qatlamiga yetkazishi kerak.
Write-ahead log
Ko‘p database tizimlari avval o‘zgarishni write-ahead logga ketma-ket yozadi. Data page’larning diskka yozilishi keyinroq bajarilishi mumkin. Restartdan keyin recovery commit qilingan log recordlarini redo qilib, data fayllarini yakuniy holatga keltiradi. Commit qilinmagan ishlar undo yoki visibility qoidalari orqali chiqarib tashlanadi.
Log buffer faqat process memory’sida bo‘lsa quvvat uzilishida yo‘qoladi. Commit yo‘li fsync, fdatasync yoki platformaga mos flush orqali storage’ga durability barrier yuboradi. Operatsion tizim page cache’i va disk controller cache’i buyruqni to‘g‘ri bajarishi lozim.
Guruhli commit
Har transaction uchun alohida flush katta latency keltiradi. Group commit bir vaqtda kelgan bir nechta transaction logini bitta fizik flush bilan barqarorlashtiradi. Har bir client o‘z log positioni durable bo‘lgach javob oladi. Bu throughputni oshiradi va kafolatni saqlaydi.
Asinxron commit rejimi clientga flush tugashidan oldin javob berishi mumkin. U tezroq bo‘lsa-da, server crashida yaqinda tasdiqlangan transactionlar yo‘qolish oynasini yaratadi. Bu rejim ishlatilsa “commit”ning biznes ma’nosi va ruxsat etilgan data loss aniq hujjatlashtiriladi.
Replication bilan bog‘liqlik
Lokal diskdagi durable yozuv serverning butunlay yo‘qolishidan himoya qilmaydi. Synchronous replication commitni bir yoki bir nechta replica logni qabul qilib, kerakli darajada flush qilguncha kutishi mumkin. Remote replica boshqa failure domain’da bo‘lsa chidamlilik oshadi, lekin network latency commit vaqtiga qo‘shiladi.
Asynchronous replica ortda qolishi mumkin. Primary halokatidan keyin eng yangi log hali replica’ga yetmagan bo‘lsa acknowledged transaction yo‘qoladi. RPO bu ruxsat etilgan yo‘qotish oynasini, RTO esa xizmatni tiklash vaqtini ifodalaydi.
Storage qatlamlari
Virtual disk, RAID controller, SAN va cloud block storage o‘z cache hamda replication qatlamlariga ega. Har biri flushni to‘g‘ri uzatishi kerak. Battery-backed write cache quvvat uzilishida yozuvni saqlab, qaytgach diskka tushiradi. Consumer disk buyruqni noto‘g‘ri tasdiqlasa database log algoritmi yuqori qatlamda durability yarata olmaydi.
Backupdan farqi
Durability tasodifiy DELETE, buzilgan application yoki ransomware’ga qarshi tarixiy nusxa bermaydi: database noto‘g‘ri commitni ham ishonchli saqlaydi va replica’ga uzatadi. Backup hamda point-in-time recovery alohida himoyadir. Restore sinovi arxiv loglari va base backup birga ishlashini tekshiradi.
Tekshirish
Crash test processni keskin to‘xtatish, VMni reset qilish yoki storage fault injection orqali recovery’ni sinaydi. Faqat graceful shutdown durability xatosini ko‘rsatmaydi. Monitoring log flush latency, replication acknowledgement, disk error va recovery holatini kuzatadi. Client retry qilganda commit javobi yo‘lda yo‘qolgan bo‘lishi mumkin; idempotency noma’lum natijani xavfsiz qayta ishlashga yordam beradi.
Commitning noma’lum natijasi
Server logni durable qilib, javob yuborishidan keyin network uzilsa client timeout ko‘radi, lekin transaction commit bo‘lgan bo‘lishi mumkin. Uni oddiy qayta yuborish duplicate amal yaratadi. Payment yoki order API idempotency kalitini transaction natijasi bilan birga saqlaydi; retry avvalgi javobni topadi. Durability ma’lumotni saqlaydi, clientga natija yetib borishini esa alohida protokol hal qiladi.
Bog‘liq tushunchalar
ACID, Write-ahead log, Commit, fsync, Group commit, Replication, Recovery point objective, Backup