Replica lag — replica holati primaryning joriy holatidan qanchalik ortda qolganini ifodalovchi o‘lchov. U vaqt, log byte miqdori, transaction soni yoki log sequence position farqi bilan beriladi. Bitta “lag sekundlari” ko‘rsatkichi barcha holatni tushuntirmaydi, chunki data receive qilingan bo‘lsa ham hali durable yozilmagan yoki apply qilinmagan bo‘lishi mumkin.
Bosqichlar bo‘yicha o‘lchash
Replication pipeline odatda sent, received, flushed va replayed bosqichlariga ega. Primary sent positiondan replica received positionni ayirish network yoki sender backlogini ko‘rsatadi. Received bilan flushed oralig‘i replica storage yozuvini, flushed bilan replayed farqi apply navbatini bildiradi.
Vaqtga asoslangan lag oxirgi replay qilingan transaction timestampini joriy vaqt bilan taqqoslaydi. Primaryda yangi yozuv bo‘lmasa bu qiymat noto‘g‘ri “lag” ko‘rsatishi yoki umuman o‘zgarmasligi mumkin. Clock farqi ham natijani buzadi. Position farqi aniqroq, ammo uni sekundga aylantirish write rate o‘zgaruvchan bo‘lsa murakkab.
Asosiy sabablar
Network bandwidth yetishmasligi yoki packet loss transportni sekinlashtiradi. Replica diski sust bo‘lsa flush navbati o‘sadi. Bitta apply worker, katta transaction, DDL, constraint tekshiruvi yoki CPU bosimi replayni ushlab turadi. Hot standbydagi uzoq read query recovery bilan conflict sabab applyni kechiktirishi mumkin.
Primarydagi keskin write burst tabiiy ravishda vaqtinchalik backlog hosil qiladi. Muammo faqat cho‘qqi emas, replica keyin normal tezlikda primaryga yetib ola bilishidir. Apply throughput write throughputdan doim past bo‘lsa lag cheksiz o‘sadi.
Ta’sir
Read replica stale natija beradi. Failoverda apply qilinmagan yoki hatto olinmagan log RPOga ta’sir qiladi. Uzoq lag primaryda log retentionni kattalashtirib diskni to‘ldirishi mumkin. Logical replication subscriberida schema xatosi bitta transactionda oqimni butunlay to‘xtatadi.
Kuzatuv va kamaytirish
Dashboard har bosqich positioni, byte backlog, vaqt trendi, replica resource saturation va apply xatosini birga ko‘rsatadi. Alert workloadga mos bo‘ladi: user-facing read uchun bir necha soniya ham muhim, disaster recovery nusxasi uchun boshqa chegara qo‘yilishi mumkin.
Index va querylar optimallashtiriladi, katta transactionlar qisqartiriladi, replica storage yoki CPU kengaytiriladi va parallel apply yoqiladi. Read traffic recoveryni to‘sayotgan bo‘lsa query timeout yoki alohida analytics replica ishlatiladi. Intentional delayed replica esa xato o‘chirishdan himoya uchun ataylab ortda qoladi va oddiy nosoz lagdan alohida belgilanishi kerak.
Lag va service siyosati
Har endpoint qabul qiladigan stalenessni belgilaydi. Product catalog bir daqiqalik eski qiymatni qabul qilishi mumkin, password revocation yoki account holati esa primarydan o‘qilishi kerak. Router replica health bilan birga shu siyosatga qarab readni yo‘naltiradi. Faqat barcha readlarni primaryga qaytarish lag ta’sirini yo‘qotsa ham primary overloadini kuchaytirishi mumkin.
Failover tayyorgarligida “eng kam byte lag” yagona mezon emas. Replica logni olgan, lekin diskka flush qilmagan bo‘lsa quvvat uzilishida data qolmasligi mumkin. Promotion candidate uchun receive, flush va replay holati, timeline, zone hamda quorum membership birga tekshiriladi. Lag alerti recovery runbook va qaysi trafikni cheklash qarori bilan bog‘lanadi.
Lag grafigiga deployment, backup va traffic kampaniyasi annotatsiya qilinsa takrorlanuvchi sabablar ko‘rinadi. Qisqa spike uchun keraksiz failover qilishdan ko‘ra trend va catch-up tezligini baholash to‘g‘riroq.
Bog‘liq tushunchalar
Replication, Read replica, Log sequence number, Recovery point objective, Apply worker, Replication slot, Failover, Delayed replica