Log Replication — tugunda yuz bergan tartibli operatsiya yozuvlarini boshqa replica’larga ko‘chirib, ularning state’ini bir xil tarixdan tiklash mexanizmi. U taqsimlangan tizimdagi aniq consistency, replication yoki fault-handling masalasini ifodalaydi. Kafolatlar faqat termin nomidan emas, protocol modeli, failure farazlari va implementatsiya hujjatidan aniqlanadi.
Tuzilishi
Leader log entryga index va term yoki boshqa order metadata beradi. Follower oldingi entry mosligini tekshiradi, yangi yozuvni persistent saqlaydi va commit indexgacha state machinega apply qiladi.
Log Replication alohida algoritm yoki konfiguratsiya sifatida emas, client xulqi, storage persistence va tarmoq noaniqligi bilan birga ko‘riladi. Bir tugundagi muvaffaqiyat boshqa replica ham shu state’ni commit qilganini avtomatik anglatmaydi. Shu sabab acknowledgementning aniq ma’nosi va visible state chegarasi hujjatlashtiriladi.
Asosiy mexanizm
Physical log disk bloklarini, logical log esa row yoki command o‘zgarishini ifodalashi mumkin. Consensus logi qarorlar tartibini, database replication logi data o‘zgarishini tashiydi; kafolatlar implementatsiyaga bog‘liq.
Log Replication uchun durability faqat xotiradagi acknowledgementga bog‘lanmaydi. Qaysi nuqtada log diskka yozilgani, replica nechta failure domainni qamragani va power lossdan keyin qanday tiklanishi aniqlanadi. Cloud zone yoki rack nomi mustaqil failure ekanini avtomatik kafolatlamaydi.
Nosozlik xulqi
Gap recovery, log truncation, snapshot boundary va schema compatibility muhim. Follower divergent suffixni noto‘g‘ri saqlab qolsa bir xil index turli operatsiyani anglatishi mumkin.
Log Replication dizaynida safety va liveness ajratiladi. Safety buzilishi qarama-qarshi commit yoki noto‘g‘ri qiymatga, liveness buzilishi esa tizimning oldinga siljimasligiga olib keladi. Timeoutni qisqartirish livenessni tezlashtirishi mumkin, biroq sekin tarmoqda false failure va keraksiz leader almashishini oshiradi.
Sinov va kuzatuv
Log Replication capacity rejasi odatiy trafikdan tashqari failure paytidagi catch-up va retry yukini ham hisoblaydi. Bir replica yo‘qolganda qolganlar client request bilan birga rebuild oqimini ko‘taradi. Backpressure va admission control queue cheksiz o‘sishidan ko‘ra bashorat qilinadigan degradation beradi.
Log Replicationni tanlash workload semantikasidan boshlanadi. Hisob-kitob, inventory, user preference va analytics bir xil conflict yoki isolation talabiga ega emas. Qat’iyroq kafolat har doim eng yaxshi yechim bo‘lmasligi mumkin, chunki latency va partition paytidagi availability kamayadi; zaifroq model esa application zimmasiga merge va invariant tekshiruvini yuklaydi. Qaror texnologiya nomi bilan emas, qaysi anomaly qabul qilinishi yoki mutlaqo taqiqlanishi yozilgan jadval bilan asoslanadi.
Log Replication holatini kuzatishda configuration version, role yoki epoch, commit nuqtasi, queue va log ko‘rsatkichlari birlashtiriladi. Alert operator bajara oladigan tekshiruvga bog‘lanadi: qaysi node, qaysi key yoki transaction va qaysi vaqt oralig‘i ko‘rilishi aniq yoziladi. Aggregate dashboarddan keyin xom dalil bilan tasdiqlash noto‘g‘ri tashxisni kamaytiradi.
Log Replicationga oid bahoni qayta ishlab bo‘lishi uchun test topologiyasi, software versiyasi, fault injection va kutilgan invariant saqlanadi. Yakuniy natija taxmin yoki bitta log satriga emas, bir-birini tasdiqlovchi state, history va o‘lchovlarga asoslanadi. Qabul qilingan cheklovlar ham natija bilan birga yozilib, boshqa workloadga ko‘r-ko‘rona ko‘chirilmaydi.
Bog‘liq tushunchalar
replicated log, leader follower, commit index, write-ahead log, snapshot, consensus