Primary — replicated database guruhida authoritative yozuvlarni qabul qiladigan va ularning tartibini replication log orqali boshqa nusxalarga uzatadigan tugun roli. U leader deb ham ataladi; “primary” atamasi storage yoki network interfeysining asosiy nusxasi kabi boshqa kontekstlarda ham uchrasa-da, database replicationda odatda write authorityni bildiradi.
Yozuv oqimi
Client transactionni primaryga yuboradi. Database o‘zgarishlarni write-ahead log, binlog yoki boshqa tartiblangan jurnalga yozadi, commit qoidasini bajaradi va replika tugunlariga log pozitsiyasini uzatadi. Replicalar shu ketma-ketlikni qayta ijro etib, primary holatiga yaqinlashadi.
Primary barcha o‘qishlarni bajarishi shart emas. Read traffic replikalarga yo‘naltirilishi mumkin, ammo ular ortda qolsa stale natija qaytaradi. “Yozdim, darhol o‘qidim” talabi uchun primarydan o‘qish, session stickiness yoki ma’lum log pozitsiyasigacha replika apply qilganini kutish ishlatiladi.
Bitta yozuvchi prinsipi
Ko‘p tizim bir vaqtda faqat bitta primaryga ruxsat beradi. Network partition paytida ikki tugun yozuv qabul qilsa split-brain va divergent history yuzaga keladi. Quorum, lease va fencing eski primaryning storage yoki client trafficga kirishini to‘xtatadi. DNS yoki load balancer yo‘nalishini o‘zgartirishning o‘zi fencing o‘rnini bosmaydi.
Failover va promotion
Primary ishlamay qolsa coordinator eng dolzarb, mos va quorumga ulangan replikani tanlaydi. Promotion undan yangi timeline yoki term boshlashni va write endpointni ko‘chirishni talab qiladi. Asynchronous replicationda oxirgi tasdiqlangan yozuvlar hali replikaga yetmagan bo‘lishi mumkin; demak failover nol data lossni avtomatik kafolatlamaydi.
Eski primary qaytganda u bevosita clusterga primary sifatida qo‘shilmaydi. Uning tarixi tekshiriladi, kerak bo‘lsa rewind yoki to‘liq resync qilinadi va replica rolida qaytariladi. Aks holda eski yozuvlar yangi primary tarixiga aralashishi mumkin.
Amaliy boshqaruv
Health check faqat port ochiqligini emas, tugun haqiqatan write-capable primary ekanini tekshiradi. Monitoring role, term, log position, replica lag, commit latency va failover sababini qayd etadi. Connection poollar topologiya almashganda eski connectionlarni yopishi kerak.
Primary backupning o‘zi emas. Operator xatosi yoki noto‘g‘ri delete replication orqali barcha nusxalarga tarqaladi; point-in-time recovery uchun mustaqil backup va saqlangan log zarur. Primaryning yuqori availabilitysi durability va disaster recovery talablarini alohida loyihalash ehtiyojini yo‘qotmaydi.
Topologiyani clientga ko‘rsatish
Client primary manzilini static host sifatida bilsa failoverdan keyin eski tugunga qaytishi mumkin. Stable write endpoint, service discovery yoki topology-aware driver role o‘zgarishini client connectionlariga yetkazadi. Driver “read-write” session ochib, serverning recovery yoki read-only holatini tekshirishi mumkin. Transaction o‘rtasida connection uzilsa client commit bo‘lgan-bo‘lmaganini aniq bilmasligi ehtimol; operation ID va idempotency key noaniq natijani xavfsiz qayta tekshirishga yordam beradi.
Planned switchoverda eski primary writesni to‘xtatadi, tanlangan replica oxirgi loggacha yetadi va keyin promotion qilinadi. Bu jarayon emergency failoverdan ko‘ra data loss xavfini kamaytiradi. Role almashuvi audit qilinadi, chunki tez-tez asossiz failover connection churn va replica resync xarajatini oshiradi.
Schema migration primaryda bajarilganda replica apply capacitysi ham hisoblanadi. Katta index qurilishi yoki table rewrite log hajmini keskin oshirib, odatiy write latency normal bo‘lsa ham failover tayyorgarligini yomonlashtirishi mumkin.
Bog‘liq tushunchalar
Replica, Leader election, Failover, Write-ahead log, Split-brain, Fencing, Read-after-write consistency