Database Replication — Senior chuqurlik

Physical (streaming) replikatsiya

WAL’ning bayt darajasidagi yozuvlari to‘g‘ridan-to‘g‘ri replikaga oqadi. Replika — primary’ning aniq binar nusxasi (xuddi shu fayl bloklari). Tez va oddiy, lekin: butun klaster ko‘chadi (tanlab bo‘lmaydi), bir xil major versiya talab qiladi, replika faqat o‘qishga ochiq (hot standby).

Logical replikatsiya

WAL qatorlar darajasidagi o‘zgarishlarga (INSERT/UPDATE/DELETE) "dekod" qilinadi (logical decoding). Endi jadval tanlab, versiyalar aro, hatto transform bilan replikatsiya qilish mumkin:

-- LOGICAL replikatsiya: jadval darajasida, publish / subscribe
-- primary (publisher):
CREATE PUBLICATION orders_pub FOR TABLE orders, order_items;
-- replica (subscriber):
CREATE SUBSCRIPTION orders_sub
  CONNECTION 'host=primary dbname=shop'
  PUBLICATION orders_pub;
-- +  cross-version, tanlab (subset), transform, ko'p manba -> bitta nishon
-- -  DDL va sequence avtomatik ko'chmaydi; sekinroq

synchronous_commit darajalari — har biri boshqa kafolat

# postgresql.conf — primary'da sinxron replikatsiya
wal_level = replica                # logical replikatsiya uchun -> logical
max_wal_senders = 10
synchronous_commit = on            # standby WAL'ni DISKKA flush qilguncha kut

# QUORUM sinxron: 3 standby'dan ISTALGAN 1 tasi tasdiqlasa yetarli
# (bittasi o'lsa ham yozuv bloklanmaydi -> mavjudlik + durability balansi)
synchronous_standby_names = 'ANY 1 (s1, s2, s3)'

Nega quorum (ko‘pchilik) kerak

Tarmoq bo‘linsa, ikkala tomon ham "men primary bo‘laman" desa — split-brain. Yechim: primary bo‘lish uchun tugunlarning yarmidan ko‘pi (quorum) ovoz berishi shart. Bo‘lingan tarmoqda faqat bitta tomon ko‘pchilikka ega bo‘ladi — ikkinchisi primary bo‘la olmaydi.

Raft va DCS

Raft — konsensus algoritmi: leader saylanadi (term bilan), yozuvlar ko‘pchilikka takrorlangach "committed" bo‘ladi. Amalda buni o‘zing yozmaysan — DCS (Distributed Configuration Store: etcd, Consul, ZooKeeper) bu konsensusni beradi (etcd ichida Raft ishlaydi). Patroni (keyingi bo‘lim) klaster holatini shu DCS’da saqlaydi.

Patroni qanday ishlaydi

Har node’da Patroni agenti ishlaydi va u PostgreSQL’ni boshqaradi. Klaster holati DCS (etcd)da saqlanadi. Mexanizm — leader lock + TTL:

• Joriy leader (primary) DCS’da "leader" kalitini TTL bilan ushlab turadi va uni doim yangilaydi.
• Leader yiqilsa — yangilay olmaydi, TTL tugaydi, kalit bo‘shaydi.
• Sog‘lom replikalar kalitni egallashga poyga qiladi; atomik tarzda bittasi yutadi (etcd konsensusi tufayli) → o‘zini primary’ga promote qiladi.
• HAProxy/pgbouncer Patroni’ning REST sog‘liq endpointiga qarab trafikni doimo joriy leaderga yo‘naltiradi.

# patroni.yml — har node'da ishlaydi (PostgreSQL + Patroni agent)
scope: shop-cluster
etcd:
  hosts: "etcd1:2379,etcd2:2379,etcd3:2379"     # DCS (konsensus shu yerda)
bootstrap:
  dcs:
    ttl: 30                       # leader lock muddati (sekund)
    loop_wait: 10                 # har 10s da holatni tekshiradi
    retry_timeout: 10
    maximum_lag_on_failover: 1048576   # 1MB dan ko'p orqada replika PROMOTE BO'LMAYDI
    postgresql:
      use_pg_rewind: true
      parameters:
        synchronous_commit: "on"
        synchronous_standby_names: "ANY 1 (*)"

Nega va nega yo‘q

+ Har mintaqada yozuv (past kechikish), yozuvda yagona bottleneck yo‘q, bitta node o‘lsa boshqasi yozadi. − Eng katta muammo — yozuv konflikti: ikki node bir paytda bir xil qatorni o‘zgartirsa, qaysi biri to‘g‘ri?

Konflikt yechish strategiyalari

Asosiy naqsh — bitta yozuv mintaqasi + geo o‘qish replikalari

Yozuv bitta "uy" mintaqada; boshqa mintaqalarda o‘qish replikalari. Foydalanuvchi o‘ziga yaqin replikadan tez o‘qiydi, yozuv esa uzoqdagi primary’ga boradi.

Lag’ni o‘lchash

Postgres pg_stat_replication jadvalida har replika holati ko‘rinadi — bayt (qancha WAL orqada) va vaqt (necha sekund orqada):

-- LAG monitoring: bayt va vaqt bo'yicha (primary'da ishga tushiriladi)
SELECT
  client_addr,
  state,                                                   -- streaming / catchup
  pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes,
  replay_lag AS lag_time                                   -- vaqt bo'yicha orqada qolish
FROM pg_stat_replication;

Lag sabablari va vositalar

• Yozuv portlashi: primary’da to‘satdan ko‘p yozuv — replika yetisha olmaydi.
• Replikadagi uzoq so‘rovlar: og‘ir analitik so‘rov WAL’ni qo‘llashni (replay) bloklaydi.
• Tarmoq: mintaqalararo yoki tor kanal.

Senior HA arxitekturasi — yig‘ma ko‘rinish

Yetuk, ishonchli PostgreSQL HA odatda shunday quriladi:

Senior tayyorlik cheklisti