Crash consistency — tizim kutilmaganda to‘xtagan paytdagi disk holati qayta ishga tushganda filesystem yoki application recovery mexanizmlari bilan o‘qiladigan holatga kelish xususiyatidir. Crash-consistent snapshot elektr uzilgan kompyuter diskiga o‘xshaydi: barqaror storagega yetgan yozuvlar bor, xotiradagi bufferlar esa yo‘qolgan bo‘lishi mumkin.
Yozuvlar tartibi
Application bir mantiqiy amal uchun bir nechta block yozishi mumkin. Storage va operatsion tizim performance uchun ularni reorder qiladi. Crash metadata yangilanib, data hali yozilmagan oraliqda sodir bo‘lsa nom mavjud, mazmun esa eski yoki qisman bo‘lishi mumkin.
fsync ma’lum file yozuvlarini barqaror storagega chiqarishni talab qiladi. Rename orqali atomic file replace qilishda yangi file’ni, so‘ng directory metadata’sini sync qilish kerak bo‘lishi mumkin. Aniq kafolat filesystem va hardware cache semantikasiga bog‘liq.
Filesystem journaling
Journal metadata yoki data update’larni transaction sifatida qayd etadi. Recovery tugallanmagan transactionni bekor qiladi yoki committed transactionni replay qiladi. Bu filesystem strukturasini buzilmas holga keltiradi, ammo har application recordi biznes jihatdan to‘liq ekanini kafolatlamaydi.
Metadata journaling file length va directoryni himoya qilishi, payload ichida yarim yozilgan application record qolishi mumkin. Checksummed log record va length prefix parserga incomplete tailni aniqlash imkonini beradi.
Database recovery
Database Write-Ahead Log’da data page’dan oldin change recordni barqaror saqlaydi. Crashdan keyin committed transactionlar redo, commit qilinmaganlari undo yoki MVCC visibility orqali yashiriladi. Checkpoint recovery boshlanish nuqtasini qisqartiradi.
Database process ishlayotganida storage snapshot olish data file va WALni bir nuqtada ushlashi kerak. Engine crash recovery’ni bajara olsa snapshot crash-consistent bo‘lishi mumkin. WAL yoki control file scope’dan tashqarida qolsa recovery imkonsizlashadi.
Bir nechta volume
Data va log turli volume’da bo‘lsa snapshotlar soniyalar farqi bilan yaratilishi xavfli. Consistency group storage markerini bir vaqtda qo‘yadi. Biroq guest RAM va application bufferlar baribir kirmaydi.
Distributed database’da har node’ning alohida crash-consistent snapshoti clusterning umumiy transaction nuqtasiga teng emas. Consensus log, backup protocol yoki coordinated checkpoint zarur.
Crash test
Clean shutdown testi crash consistency’ni tekshirmaydi. Fault injection processni kill -9, VM power-off yoki storage failure bilan kutilmagan joyda to‘xtatadi. Qayta ishga tushgach recovery logi, checksum va application invariantlari tekshiriladi.
Test turli write bosqichlarini ko‘p marta nishonga oladi. Timing nondeterministic bo‘lsa failpointlar aniq code locationda crash yaratadi. Production data emas, isolated test image ishlatiladi.
Snapshot va backup
Crash-consistent snapshot tez olinadi va guest bilan integratsiya talab qilmaydi. Stateless server yoki jurnalga ega filesystem uchun yetarli bo‘lishi mumkin. In-memory queue, ochiq transaction va bir nechta application orasidagi workflow uchun data yo‘qotish yoki semantik nomoslik qoladi.
Restore’dan keyin faqat filesystem mount bo‘lishi yetarli tekshiruv emas. Database recovery tugashi, service start bo‘lishi va invariant querylar o‘tishi kerak. RPO barqaror storagega yetmagan oxirgi write’larni hisobga oladi.
Hardware cache
Disk yoki controller write-back cache completionni data persistent mediaga yetishidan oldin bildirishi mumkin. Power-loss protection bo‘lmasa tok uzilishida tasdiqlangan yozuv yo‘qoladi. Flush va Force Unit Access buyruqlari device tomonidan to‘g‘ri bajarilishi zarur. Virtual disk, RAID controller va physical drive qatlamlaridan bittasi flushni inkor qilsa yuqori qatlam fsync kafolati zaiflashadi. Durability testi haqiqiy stack konfiguratsiyasida bajariladi.
Bog‘liq tushunchalar
Application consistency, Write-Ahead Log, Filesystem journal, fsync, Snapshot, Checkpoint, Fault injection