Asynchronous replication — primary transactionni replica o‘zgarishni olganini kutmasdan commit qiladigan replication rejimi. Primary logni mahalliy commit qoidasiga muvofiq saqlagach clientga javob beradi, replica esa logni keyinroq olib apply qiladi. Bu write latency va availabilityni yaxshilaydi, biroq failover paytida yaqinda tasdiqlangan yozuvlar yo‘qolishi mumkin.
Ma’lumot yo‘li
Primary har bir o‘zgarishga log sequence yoki boshqa monoton position beradi. Sender yangi log segmentlarini uzatadi; replica receive, durable write va replay bosqichlaridan o‘tadi. Bu bosqichlar parallel ishlagani uchun replica doim primary bilan aynan bir xil nuqtada bo‘lishi shart emas.
Network uzilganda primary odatda yozishni davom ettiradi. Yetishmagan log saqlansa replica aloqadan keyin catch-up qiladi. Primary logni replica olmasidan oldin o‘chirsa archive yoki yangi base backup kerak bo‘ladi. Shu sabab replication slot yoki retention sozlamasi lag bilan disk to‘lishi o‘rtasida boshqariladi.
Lag va o‘qish
Replica lag vaqt, byte yoki log position farqi bilan o‘lchanadi. Faqat transport lagini ko‘rish yetarli emas: log yetib kelgan, ammo apply sekin bo‘lishi mumkin. Replikadan o‘qigan client eski holatni ko‘radi. Read-after-write kerak bo‘lsa primaryga qaytish yoki kerakli position apply bo‘lguncha kutish ishlatiladi.
Analytics querylari, report va cache uchun ozgina staleness qabul qilinishi mumkin. Inventory yoki account balance kabi qarorlar esa stale read sabab noto‘g‘ri amal bajarishi mumkin.
Failoverdagi xavf
Primary birdan yo‘qolsa, eng yangi replica ham uning oxirgi loglarini olmagan bo‘lishi ehtimol. Promotion qilingan replica tarixida bu commitlar bo‘lmaydi. Eski primary qaytsa, undagi alohida yozuvlarni avtomatik qo‘shish xavfli; timeline tekshirilib, biznes darajasida reconciliation talab qilinishi mumkin.
Asynchronous replikatsiyaning amaliy RPOsi lag va nosozlik turiga bog‘liq. “Odatda bir soniya lag” qat’iy bir soniyalik RPO kafolati emas, chunki overload yoki partition vaqtida farq keskin o‘sadi.
Boshqaruv
Monitoring sent, received, flushed va replayed positionlarni, lag trendini, log retention hajmini hamda apply xatolarini kuzatadi. Alert faqat sekund chegarasi emas, workload va RPO bilan moslashtiriladi. Uzoq transaction yoki katta schema o‘zgarishi applyni ushlab qolishi mumkin.
Asynchronous replication geografik disaster recovery, read scaling va uzoq masofali nusxa uchun keng ishlatiladi. Muhim yozuvlarda synchronous replica, commit acknowledgement yoki application-level outbox bilan aralash model tuziladi. Replikalar xato delete va corruptionni ham ko‘chirishi mumkinligi uchun alohida backup zarur.
Replikadan xavfsiz foydalanish
Traffic manager replica lag limitdan oshsa uni read pooldan chiqarishi mumkin. Bu qaror keskin bo‘lmasligi uchun hysteresis qo‘llanadi: qayta poolga kirish uchun lag bir muddat past turadi. Replica read-only qilinadi, chunki local write keyingi apply bilan conflict yoki failoverda yo‘qoladigan alohida holat yaratadi.
Cross-region topologiyada bandwidth uzilishi paytida backlog qanchalik tez o‘sishi oldindan hisoblanadi. Link tiklangach catch-up oqimi user trafficni siqib qo‘ymasligi uchun bandwidth cap yoki priority beriladi. Planned switchover oldidan writes qisqa to‘xtatilib, target replica aniq log positiongacha yetkaziladi. Shu yo‘l emergency promotionga qaraganda RPOni nolga yaqinlashtiradi va divergent timeline ehtimolini kamaytiradi.
Bog‘liq tushunchalar
Replication, Replica lag, Primary, Failover, Recovery point objective, Log sequence number, Read replica, Backup