Synchronous replication — primary transaction commitini tasdiqlashdan oldin bir yoki bir nechta replica o‘zgarishni belgilangan bosqichgacha qabul qilganini kutadigan replication rejimi. Bu failoverda yo‘qolishi mumkin bo‘lgan tasdiqlangan ma’lumotni kamaytiradi, evaziga write latency va replica yoki tarmoq nosozligiga sezgirlikni oshiradi.
Tasdiq bosqichlari
“Replica tasdiqladi” bir necha ma’noga ega. Ma’lumot network bufferiga kelgan, replica operatsion tizimi uni yozgan, storagega durable flush qilgan yoki database engine o‘zgarishni apply qilgan bo‘lishi mumkin. Flush acknowledgement odatda replica quvvati uzilganda ham log saqlanishini ko‘zlaydi. Apply acknowledgement esa yangi qiymat o‘qishga ko‘rinishini ham kutadi va ko‘proq vaqt oladi.
Shuning uchun synchronous so‘zi yakka o‘zi nol data loss yoki darhol read visibility degani emas. Commit qoidasida nechta replica, qaysi bosqich va qanday timeout talab etilishi aniq yoziladi.
Quorumli variant
Fixed synchronous replica modelida tanlangan bitta standby javob berishi kerak. U sekinlashsa butun write yo‘li sekinlashadi. Quorum modelida, masalan, uch nomzoddan istalgan ikkitasi tasdiqlashi mumkin. Bu bir tugun nosozligiga chidamlilik beradi, ammo quorum joylashuvi mustaqil failure domainlarni qamrashi kerak.
Primaryning local durable writei bilan replica acknowledgementlari birgalikda commit policy hosil qiladi. Witness faqat ovoz berib, ma’lumotni saqlamasa u durability nusxasi hisoblanmaydi.
Latency va mavjudlik
Commit vaqti odatda primary storage va eng sekin talab etilgan acknowledgementning network hamda storage vaqtini o‘z ichiga oladi. Uzoq regionlar orasida synchronous replication round-trip latency sabab qimmat. Bir region ichidagi zonalar muvozanatli yechim bo‘lishi mumkin, lekin zonalararo uzilishda quorum yo‘qolsa writes to‘xtaydi.
Ba’zi tizim timeoutdan keyin asynchronous rejimga tushadi, boshqalari commitni rad etadi. Avtomatik fallback availabilityni saqlaydi, lekin aynan nosozlik vaqtida RPOni o‘zgartiradi; bu holat monitoring va alertda ko‘rinishi shart.
Ishlatish va tekshirish
Moliyaviy ledger yoki tasdiqlangan buyurtma kabi data loss narxi yuqori yozuvlarda synchronous replication tanlanadi. Cache, telemetry yoki qayta hosil qilinadigan ma’lumot uchun asynchronous rejim yetarli bo‘lishi mumkin.
Sinovda replica processini, tarmoqni va butun zonani alohida uzib, write behavior o‘lchanadi. Commit latency percentillari, acknowledgement holati, quorum a’zolari va fallback soni kuzatiladi. Synchronous replica backup o‘rnini bosmaydi, chunki logical xato ham barcha nusxalarga sinxron tarqaladi.
Replikani tanlash
Synchronous nomzodlar bir xil capacityga ega bo‘lmasa, sekin diskli tugun commit yo‘lini boshqarib qolishi mumkin. Priority, lag threshold va dynamic candidate selection buni cheklaydi. Biroq juda ortda qolgan yangi replica tasdiqchi bo‘lishidan oldin to‘liq catch-up qilishi kerak. Aks holda failoverda kerakli loglar unda mavjud bo‘lmaydi.
Application uchun transaction javobi semantikasi hujjatlanadi. Client timeout ko‘rsa primary commitni replica tasdiqlagan, lekin javob networkda yo‘qolgan bo‘lishi mumkin. Bu “unknown commit outcome”ni anglatadi; bir xil payment yoki orderni ko‘r-ko‘rona qayta yaratish mumkin emas. Idempotency key, unique constraint va status lookup yordamida avvalgi transaction natijasi aniqlanadi.
Commit policy o‘zgarishi configuration auditida saqlanadi. “Vaqtincha” asynchronous fallback incident tugagach unutilib qolmasligi uchun holat service health va deployment gate’da tekshiriladi.
Bog‘liq tushunchalar
Replication, Primary, Replica, Quorum, Commit latency, Durability, Failover, Recovery point objective