Crash recovery — process, operatsion tizim yoki server kutilmaganda to‘xtaganidan keyin database’ni transaction jihatdan izchil holatga qaytarish jarayoni. U committed o‘zgarishlarni saqlab qolish va tugallanmagan transactionlarni foydalanuvchiga ko‘rinmas qilishga qaratilgan.
Crash turi
Process crash faqat database processlarini, system crash butun operatsion tizimni to‘xtatadi. Power loss volatile cache’dagi ma’lumotni yo‘qotishi mumkin. Media failure esa disk yoki storage’dagi durable data’ning o‘zini buzadi. Oddiy crash recovery odatda birinchi uch holatda sog‘lom persistent storage mavjud deb hisoblaydi; media failure uchun backup yoki replica kerak.
Graceful shutdown barcha ishni yakunlab checkpoint yaratishi mumkin. Crash’da bunday imkon yo‘q, shuning uchun diskdagi data file’lar turli vaqtdagi page’larni o‘z ichiga olishi mumkin.
Redo va undo
Write-ahead log data page’dan oldin o‘zgarish yozuvini saqlaydi. Startup recovery oxirgi checkpoint atrofidan logni tahlil qilib, diskka hali tushmagan committed o‘zgarishlarni redo qiladi. Operation idempotent yoki LSN bilan himoyalangan bo‘lsa, allaqachon qo‘llangan recordni qayta ko‘rish page’ni buzmaydi.
Ba’zi engine’lar tugallanmagan transaction ta’sirini undo log orqali bekor qiladi. PostgreSQL MVCC modelida aborted yoki in-progress transaction yaratgan tuple’lar visibility qoidalari bilan ko‘rinmaydi va keyin vacuum tomonidan tozalanadi. Implementatsiya mahsulotga qarab farq qiladi.
Torn page va checksum
Storage page’ning faqat bir qismini yozib, crash bo‘lsa torn page yuz beradi. WALdagi full-page image, doublewrite buffer yoki atomic write mexanizmi buni tiklashga yordam beradi. Page checksum buzilishni aniqlaydi, ammo sog‘lom nusxa yoki log bo‘lmasa o‘zi ma’lumotni qaytarmaydi.
Disk controller write cache flush va barrier semantikasini to‘g‘ri bajarishi kerak. Hardware “yozildi” deb yolg‘on javob bersa transaction log ham yo‘qolishi mumkin.
Startup jarayoni
Database odatda lock/pid file va oldingi shutdown holatini tekshiradi, control metadata’dan checkpointni topadi, logni replay qiladi va yangi transactionlarga ochiladi. Recovery davomida ayrim tizimlar read-only queryga ruxsat berishi mumkin, boshqalari to‘liq tugashini kutadi.
Log zanjiridagi bitta segment yo‘q yoki corrupt bo‘lsa startup to‘xtashi mumkin. Logni majburan reset qilish data loss va izchillik buzilishi xavfini tug‘diradi; backup nusxa olinib, mahsulotga xos recovery tartibi bilan bajariladi.
Taqsimlangan holat
Replica yoki consensus clusterda bitta node crash recovery qilishi bilan umumiy muammo tugamaydi. Node logini qayta o‘qib, leaderdan yetishmagan yozuvlarni oladi. Eski leader qaytganda fencing va term/epoch uning stale write yuborishini cheklaydi.
Ikki bosqichli transactionlarda prepared holat alohida qayd etiladi. Coordinator yo‘qolsa participant commit yoki rollback qarorini bilmay kutishi mumkin. Recovery loglari distributed transaction IDni saqlaydi.
Sinov va kuzatuv
Recovery duration, replay LSN, WAL backlog, checksum error va startup phase monitoring qilinadi. RTO log generatsiyasi va storage replay throughputiga bog‘liq. Faqat normal restart testi crash holatini ifodalamaydi.
Nazoratli testlarda process kill, VM power-off, disk-full va replica lag alohida bajariladi. Transaction invariantlari, committed acknowledgementdan keyingi data va keyingi writes tekshiriladi. Crash recovery backup restore va disaster recoverydan boshqa, ammo ularning chegaralari birga hujjatlashtiriladi.
Tiklanish sinovi faqat xizmat qayta ishga tushganini emas, tasdiqlangan tranzaksiyalar saqlanganini va tasdiqlanmaganlari ko‘rinmasligini ham tekshiradi. Nazorat summalari hamda invariantlar yashirin buzilishlarni aniqlashga yordam beradi.
Bog‘liq tushunchalar
Write-Ahead Log, Checkpoint, Redo log, Undo log, MVCC, Torn page, Point-in-time recovery, Durability