Recovery Manager — crash yoki transaction abortidan keyin database’ni consistent holatga qaytaradigan komponent. U taqsimlangan messaging, event-driven arxitektura yoki ma’lumotlar bazasi ichki ishlashida aniq vazifani bajaradi. Kafolatlar implementatsiya va konfiguratsiyaga bog‘liq; atamaning o‘zi durability, ordering yoki consistency darajasini avtomatik belgilamaydi.
Arxitekturadagi o‘rni
Write-ahead log recordlari orqali committed o‘zgarish redo, incomplete transactionlar undo qilinadi. Checkpoint restartda ko‘riladigan log oralig‘ini qisqartiradi.
Recovery Manager alohida modul sifatida ko‘rinsa ham, uning natijasi qo‘shni qatlamlar bilan belgilanadi. Input qabul qilinishi, state persistent bo‘lishi va consumer yoki query natijasida ko‘rinishi turli vaqt nuqtalari bo‘lishi mumkin.
Ma’lumot oqimi
Backup disasterdan nusxa tiklaydi; recovery manager odatda database log va page’lari yordamida recent crashni avtomatik tiklaydi. Replication recoveryning barcha turlarini almashtirmaydi.
Recovery Manager masshtabida o‘rtacha throughput yetarli ko‘rsatkich emas. Burst, hot key, katta transaction, sekin consumer va recovery replay tail latencyni o‘zgartiradi. Capacity sinovi steady-state bilan birga node yo‘qolgan paytdagi qo‘shimcha yukni ham qamrab oladi. Recovery Manager uchun mas’ul komponent health signalidan tashqari, o‘zi himoya qiladigan invariant buzilmaganini ham davriy ravishda tekshiradi.
Recovery Manager uchun lifecycle yaratilish, faol ishlash, migratsiya va tozalash bosqichlariga ajratiladi. Har bosqichda qaysi state authoritative ekani va eski nusxa qachon xavfsiz o‘chirilishi ko‘rsatiladi. Cutover faqat wall-clock vaqtiga emas, offset, version yoki transaction boundary’ga bog‘lansa delayed message sabab eski holatning qayta faollashish xavfi kamayadi.
Muhim farqlar
Torn page, corrupted log, disk full va crash during recovery sinov qilinadi. Log archive hamda checkpoint mavjudligi emas, amaliy restore testi kafolat beradi.
Recovery Manager configurationi deklarativ va versiyalangan saqlanadi. Vaqtinchalik override egasi, sababi va expiry muddatiga ega bo‘ladi. Yashirin default keyingi incidentda bir xil inputning boshqa environmentda nega boshqacha ishlaganini topishni qiyinlashtiradi.
Correctness, latency, throughput va storage xarajati birga tanlanadi. Tezroq acknowledgement yoki ko‘proq parallelism kiritilganda buffer, ordering va recovery talablari o‘zgaradi. Shu sabab Recovery Manager bo‘yicha qaror faqat nominal benchmarkga tayanmaydi.
Ekspluatatsiya
Recovery Manager recovery runbooki amalda mashq qilinadi. Backup, log yoki checkpoint mavjudligi yetarli emas; serializer, catalog, external dependency va cutover boundary bilan birga tiklangan natijaning invariantlari tekshiriladi.
Recovery Manager xatosi aniqlanganda avval zarar ko‘lami chegaralanadi. Muammoli partition, query yoki subscription ajratilib, yangi traffic nazoratli sekinlatiladi; forensic tahlil uchun log va state evidence saqlab qolinadi.
Recovery Manager algoritmi deterministic deb qaralsa, bir xil boshlang‘ich state va input tartibi qayta bajarishda bir xil natija berishi tekshiriladi. Random seed, clock, locale yoki parallel scheduling yashirin input bo‘lsa, replay va diagnostika uchun ular ham qayd etiladi.
Recovery Managerning API yoki protocol contracti consumer kutadigan minimum kafolatni ifodalaydi. Implementation kuchliroq tartib yoki durability bergan bo‘lsa ham client hujjatsiz xulqqa tayanmaydi, chunki upgrade uni o‘zgartirishi mumkin. Contract test producer, broker, database va consumer versiyalari kombinatsiyasida avtomatik bajariladi.
Recovery Manager o‘zgartirilgach normal oqim bilan birga malformed input, timeout, duplicate, restart va partial failure tekshiriladi. Qabul qilingan cheklovlar hujjatlashtiriladi; boshqa workload yoki platformaga ko‘r-ko‘rona ko‘chirilmaydi.
Bog‘liq tushunchalar
write-ahead log, redo, undo, checkpoint, crash recovery, ARIES