7-mavzu · Database Replication

Bu darsda nima bor

1–5-qismlar replikatsiyani noldan quradi: nega kerak, Primary-Replica modeli, sinxron/asinxron, replication lag va read-your-writes, NestJS/Prisma implementatsiya. 6-qism failover va high availability’ni (split-brain xavfi bilan) ochadi. 7-qism qachon va qanday ishlatish kerakligini hal qiladi.

Replication · qism 1

Nega kerak — SPOF va o‘qish yuki

📑

Oddiy o‘xshatish: muhim hujjatning bir nechta bir xil nusxasini turli joylarda saqlaysiz. Bittasi yo‘qolsa — nusxasi bor. Bir vaqtning o‘zida ko‘p kishi o‘qishi ham mumkin (har kim o‘z nusxasidan).

Bitta PostgreSQL serveringiz bor — barcha yozuv va o‘qish unga tushadi.

Muammo (ikki tomonlama)

1. Yagona zaiflik nuqtasi (SPOF): u tunda ishdan chiqsa — butun ilova o‘chadi, hech qanday zaxira yo‘q. Tiklash soatlab davom etishi mumkin.
2. O‘qish yuki: real ilovalarda o‘qish yozishdan 10–100 barobar ko‘p. Barcha o‘qish ham shu bitta serverga tushib, uni yuklab tashlaydi.

Yechim — replikatsiya

Ma’lumotni bir nechta serverga nusxalash. Odatda bitta Primary (asosiy) baza barcha yozuvlarni qabul qiladi va o‘zgarishlarni Replica (nusxa) bazalarga uzatadi. O‘qish so‘rovlari replikalarga taqsimlanadi. Primary o‘lsa — replikalardan biri uning o‘rnini egallaydi (failover).

Sharding bilan farqi (yana bir bor)

Replikatsiya — bir xil ma’lumotning to‘liq nusxalari (ishonchlilik + o‘qish masshtabi uchun). Sharding (6-mavzu) — ma’lumotni bo‘laklarga bo‘lish (yozuv + hajm uchun). Replikatsiya yozuvni masshtablamaydi (yozuv baribir bitta primary’da), lekin o‘qishni va ishonchlilikni beradi.

Replication · qism 2

Asosiy g‘oya — Primary va Replica

Asosiy model — Primary-Replica (eski nom: master-slave): yozuv bitta joyga, o‘qish ko‘p joyga.

Yozuv → Primary; o‘qish → ko‘p replikaga taqsimlanadi; primary o‘zgarishni replikalarga uzatadi

Bu ikki muammoni hal qiladi: ishonchlilik (primary o‘lsa, replika promote qilinadi) va o‘qish masshtabi (o‘qish ko‘p replikaga taqsimlanadi). Bundan tashqari: geografik tarqatish (foydalanuvchiga yaqin replika) va replikadan to‘xtatmasdan backup olish.

Postgres’da bu qanday

PostgreSQL streaming replication ishlatadi: primary o‘zgarishlarni WAL (Write-Ahead Log) orqali replikalarga uzatadi. Replikalar "hot standby" rejimida — ular ham o‘qishga javob bera oladi.

Replication · qism 3

Sinxron vs Asinxron va topologiya

Eng muhim qaror — primary replikani kutadimi yoki yo‘qmi. Bu izchillik va tezlik o‘rtasidagi kelishuv.

Sinxron: kafolatli, lekin sekin · Asinxron: tez, lekin lag bor

	Sinxron	Asinxron
Primary kutadimi	Ha — replika tasdiqini kutadi	Yo‘q — darhol javob beradi
Tezlik	Sekinroq (qo‘shimcha kutish)	Tez
Failover’da yo‘qotish	Yo‘q (ma’lumot kafolatlangan)	Bo‘lishi mumkin (yetib bormagan yozuvlar)
Replika o‘lsa	Yozuv bloklanadi (mavjudlik xavfi)	Yozuv davom etadi

Yarim-sinxron (semi-sync)

Amalda ko‘pincha kelishuv ishlatiladi: primary kamida bitta replika tasdig‘ini kutadi (hammasini emas). Ma’lumotni saqlash bilan tezlik o‘rtasida muvozanat. Tanlovni biznes hal qiladi (11-mavzu: CAP) — bankda sinxronga moyil, ijtimoiy lentada asinxron.

Replication · qism 4

Replication lag va read-your-writes

lag · monotonic reads

⏱️

Asinxron replikatsiyaning asosiy oqibati — lag: replika primary’dan biroz orqada. Bu ko‘rinmas xatolar manbai.

Read-your-writes muammosi

Foydalanuvchi profilini yangiladi (primary’ga yozildi), darhol sahifani qayta yukladi (o‘qish replikaga tushdi). Lekin replika hali o‘zgarishni olmagan — foydalanuvchi o‘z yangilanishini ko‘rmaydi. "Saqladim-ku, qani?" deb o‘ylaydi. Bu — replikatsiya lag’ining eng keng tarqalgan ko‘rinishi.

Yechim — yozgandan keyin primary’dan o‘qi

// READ-YOUR-WRITES: foydalanuvchi yozdi, darhol o'qiydi -> replika hali ko'rmagan!
async function createAndShow(dto) {
  const order = await prisma.order.create({ data: dto });  // PRIMARY ga yozildi
  // Agar darhol replikadan o'qisak -> "topilmadi" (lag tufayli) ✕
  // Yechim: shu o'qishni PRIMARY'dan majburlaymiz
  return prisma.$primary().order.findUnique({ where: { id: order.id } });  // ✓
}

Boshqa anomaliyalar

Monotonic reads buzilishi: ketma-ket ikki o‘qish ikki xil replikaga tushib, ikkinchisi eskiroq ma’lumot qaytarishi mumkin ("vaqt orqaga ketdi"). Yechim: bir sessiyani bitta replikaga "yopishtirish" (sticky). Umumiy qoida: lag sezgir bo‘lgan o‘qishlarni primary’ga yoki yangilangan sessiyani bir muddat primary’ga yo‘naltir.

Replication · qism 5

NestJS / Prisma implementatsiya

read replicas · $primary

Prisma read/write splitting’ni rasmiy kengaytma orqali deyarli avtomatik beradi.

1 · Prisma read replicas kengaytmasi (tavsiya etiladi)

// Prisma read replicas kengaytmasi — o'qish/yozishni avtomatik ajratadi
import { PrismaClient } from '@prisma/client';
import { readReplicas } from '@prisma/extension-read-replicas';

const prisma = new PrismaClient().$extends(
  readReplicas({
    url: [process.env.REPLICA_1_URL, process.env.REPLICA_2_URL],  // o'qish replikalari
  }),
);

// yozuvlar -> avtomatik PRIMARY ga
await prisma.order.create({ data });
// o'qishlar -> avtomatik REPLICA ga (tasodifiy tanlanadi)
await prisma.order.findMany();
// kerak bo'lsa o'qishni ham primary'dan majburlash (read-your-writes):
await prisma.$primary().order.findUnique({ where: { id } });

2 · Muqobil — ikki alohida client (ko‘proq nazorat)

// Muqobil (ko'proq nazorat): ikki alohida client
@Injectable()
export class DbService {
  readonly write = new PrismaClient({ datasources: { db: { url: PRIMARY_URL } } });
  readonly read  = new PrismaClient({ datasources: { db: { url: REPLICA_URL } } });
}
// foydalanish:
await this.db.write.user.create({ data });   // yozuv -> primary
await this.db.read.user.findMany();          // o'qish -> replica

Amaliy maslahat

Replikalar va primary URL’larini @nestjs/config orqali .envdan oling. Diqqat: o‘qish replikadan kelgani uchun biroz eskirgan bo‘lishi mumkin — yangi yozilgan ma’lumotni darhol ko‘rsatish kerak bo‘lgan joylarda $primary() ishlating.

Chuqurlashtirilgan mavzu

Failover va high availability

promote · split-brain

🔄

Replikatsiyaning asosiy maqsadlaridan biri — primary o‘lganda tizim ishlashda davom etishi. Bu jarayon — failover: replikani yangi primary’ga ko‘tarish (promote).

Failover qanday ishlaydi

Primary ishdan chiqdi → tizim buni aniqlaydi → bir replikani primary’ga promote qiladi → qolgan replikalar va ilova yangi primary’ga qayta yo‘naltiriladi. Avtomatik (sekundlarda) yoki qo‘lda bo‘lishi mumkin.

Primary o‘lsa — replika promote qilinadi, tizim ishlashda davom etadi

Qiyin tomonlari

Uchta xavf

1. Noto‘g‘ri aniqlash: primary aslida tirik, lekin tarmoq sekinlashdi — uni "o‘lik" deb hisoblab failover qilsang, muammo chiqadi.
2. Split-brain (eng xavfli): eski primary qaytib keldi yoki tarmoq bo‘lindi — endi ikkita primary bor, ikkalasi ham yozuv qabul qiladi → ma’lumot ikkiga ajraladi, izchillik buziladi.
3. Ma’lumot yo‘qolishi: asinxronda eski primary’ning replikaga yetkazmagan yozuvlari failover’da yo‘qoladi.

Yechimlar va vositalar

Split-brain’ga qarshi: quorum (ko‘pchilik ovoz bersagina primary tanlanadi) va fencing (eski primary’ni majburan o‘chirish). O‘zing qo‘lda qilma — tayyor vositalar: Patroni (PostgreSQL + etcd/Consul, avtomatik failover), repmgr, yoki boshqariladigan cloud (AWS RDS Multi-AZ, Aurora) — ular failover’ni ishonchli boshqaradi.

Qaror

Qachon va qanday ishlatish

Replikatsiya — deyarli har bir jiddiy production bazasida bo‘lishi kerak. Lekin uni to‘g‘ri ishlatish qoidalari bor.

Afzalliklar

Yuqori ishonchlilik (HA) va avtomatik failover
O‘qish so‘rovlarini masshtablash
Geografik tarqatish (foydalanuvchiga yaqin replika)
Replikadan to‘xtatmasdan backup

Cheklovlar

Yozuv hali ham bitta primary’da (yozuvni masshtablamaydi)
Asinxronda lag → eskirgan o‘qish
Failover murakkabligi (split-brain xavfi)
Qo‘shimcha serverlar va xarajat

Amaliy qoidalar

1. Har bir production bazasiga kamida bitta replika qo‘y — bu HA uchun minimal. Failover’ni tayyor vosita (Patroni/cloud) boshqarsin.

2. O‘qish ko‘p bo‘lsa — o‘qishni replikalarga taqsimla; lekin lag’ni doimo kuzat (yuqori lag = muammo).

3. Sinxron yoki asinxron — ma’lumot muhimligi bo‘yicha tanla. Yo‘qotib bo‘lmaydigan ma’lumot → sinxron/semi-sync; biroz eskirish joiz → asinxron.

4. Read-your-writesni unutma: yangi yozilgan ma’lumotni darhol ko‘rsatadigan joylarda primary’dan o‘qi.

5. Yozuv ham yetmay qolsa — replikatsiya yetmaydi, sharding (6-mavzu) kerak. Ikkalasi birga ishlatiladi.

Yakuniy

Eslab qolish kerak bo‘lgan 5 jumla

Replikatsiya = ma’lumotning to‘liq nusxalari: Primary yozadi, Replikalar o‘qiydi. Ishonchlilik (HA) + o‘qish masshtabi beradi, lekin yozuvni masshtablamaydi.
Sinxron = kafolatli, sekin (replikani kutadi); Asinxron = tez, lekin lag va failover’da yo‘qotish xavfi. Semi-sync — kelishuv.
Lag → read-your-writes muammosi: yozgandan keyin darhol o‘qishni primary’dan qil. Monotonic reads uchun sessiyani sticky qil.
NestJS/Prisma: @prisma/extension-read-replicas o‘qish/yozishni avtomatik ajratadi; $primary() bilan majburlaysan.
Failover replikani primary’ga ko‘taradi; eng xavfli — split-brain (ikki primary). Qo‘lda qilma — Patroni/cloud (RDS Multi-AZ) ishlat.

Bu mavzuning Deep/Senior qatlami (sinxron replikatsiya ichki mexanikasi, WAL/logical vs physical, quorum/Raft, Patroni sozlash, multi-primary konflikt yechish, geo-replikatsiya, lag monitoring) kerak bo‘lsa — ayting.

Yoki keyingi mavzu: “8-mavzu: API Gateway” — barcha so‘rovlar uchun yagona aqlli kirish nuqtasi.