Application consistency — backup yoki snapshot ichidagi ma’lumot applicationning o‘z transaction va invariant qoidalariga mos, qayta ishga tushirishga tayyor holatda bo‘lishidir. Bu crash consistencydan kuchliroq: disk strukturasigina emas, application bufferlari, database transactionlari va bog‘langan komponentlar ham muvofiqlashtiriladi.
Quiesce jarayoni
Snapshotdan oldin application yangi yozuvlarni qisqa muddat to‘xtatishi, pending operationlarni tugatishi va memory bufferlarini diskka chiqarishi mumkin. Bu quiescing deyiladi. Snapshot marker yaratilgach yozuvlar davom etadi.
Quiesce uzoq cho‘zilsa user request latency va timeout oshadi. Hook aniq timeoutga ega bo‘ladi; muvaffaqiyatsiz bo‘lsa snapshot crash-consistent sifatida belgilanishi yoki butunlay bekor qilinishi kerak. Noto‘g‘ri ravishda “application-consistent” deb qayd etilmaydi.
Database integratsiyasi
Database backup API checkpoint yaratadi, transaction logni rotate qiladi yoki backup mode’ga o‘tadi. Online backup davomida yozuvlar ishlashi mumkin, engine keyingi recovery uchun zarur WAL segmentlarni saqlaydi. Fayllarni oddiy copy qilish internal page update bilan poyga qilishi mumkin.
Bir database ichidagi ACID transactionlarni engine boshqaradi. Bir nechta database yoki message broker bilan bog‘langan workflow uchun distributed consistency alohida muammo. Outbox pattern restore’dan keyin database state va chiqariladigan eventlarni qayta muvofiqlashtirishga yordam beradi.
Ko‘p komponentli application
Application state database, object storage, search indeks va queue’da tarqalishi mumkin. Barchasini aynan bir millisekundda snapshot qilish amaliy emas. Authoritative source va qayta quriladigan derived state ajratiladi. Search indeks database’dan reindex qilinishi mumkin, ammo uploaded object yo‘q bo‘lsa qayta tiklanmaydi.
Consistency marker transaction ID, event offset yoki manifest orqali komponentlar orasidagi chegarani bildiradi. Restore workflow derived xizmatlarni shu markerdan qayta quradi.
Guest agent va hooklar
Virtualizatsiya platformasi guest agent orqali pre-freeze va post-thaw scriptlarni ishga tushiradi. Pre-freeze database flush qiladi, post-thaw normal ishlashni tiklaydi. Script privilege’i minimal bo‘lib, secretlarni logga chiqarmaydi.
Hooklardan biri xato bersa allaqachon muzlatilgan componentlar albatta thaw qilinadi. finally semantikasi va watchdog applicationning freeze holatida qolishini oldini oladi. Hook versiyasi application release bilan mos bo‘lishi kerak.
Restore tekshiruvi
Application-consistent deb belgilangan nusxa ham restore testidan o‘tadi. Database recovery logida unexpected corruption bo‘lmasligi, queue offset va object reference mos kelishi, business invariantlar bajarilishi tekshiriladi.
Smoke test login, read va nazoratli write’ni qamrab oladi. External payment, email yoki webhook side effectlari isolated muhitda o‘chiriladi. Schedulerlar restore paytida eski vazifani qayta yubormasligi kerak.
Cheklovlar
Application consistency snapshot vaqtidagi mantiqiy holatni beradi, undan keyingi yozuvlarni saqlamaydi. RPO backup intervali va log shippingga bog‘liq. Corruption snapshotdan oldin application tomonidan qonuniy data sifatida qabul qilingan bo‘lsa nusxada ham qoladi.
Har application vendor yoki engine o‘z backup protocoliga ega. Universal “flush hammasi” buyrug‘i barcha cache va distributed state’ni qamrab olmaydi. Runbook aniq versiya, hook va restore tartibini hujjatlashtiradi.
Message broker holati
Queue consumer avval databasega yozib, keyin acknowledgment yuborsa snapshot aynan shu ikki amal orasida olinishi mumkin. Restore’dan keyin broker eventni qayta yetkazadi; handler idempotent bo‘lishi kerak. Acknowledgment avval yuborilib, database write keyin bajarilsa crash event yo‘qotishiga olib keladi. Application-consistent recovery database snapshot bilan broker offset yoki durable outbox chegarasini bir-biriga bog‘laydi.
Bog‘liq tushunchalar
Crash consistency, Quiescing, Database backup, Checkpoint, Snapshot, Transaction, Recovery Point Objective