Ma’lumotlar bazalarini sharding va replikatsiya qilish

Ma’lumotlar bazasini sharding va replikatsiya qilish

1) Nima uchun bu zarur?

• O’tkazish qobiliyati (write QPS gorizontal o’sishi).
• Foydalanish imkoniyati (tezkor failover, yagona nuqta yo’qligi).
• Ma’lumotlarni mahalliylashtirish (ko’p mintaqa, past latentlik).
• Shovqinli qoʻshnilarni izolyatsiya qilish (hot tenants/hot keys).

2) Muvofiqlikning bazaviy atamalari va modellari

Primary/Leader Replica/Follower: peshqadamda yozish, replikalarda oʻqish.
Sinxron replikatsiya: N uzellarga yozilgandan so’ng tranzaksiyani tasdiqlash (past RPO, yuqori latentlik).
Asinxron: etakchi kommitni tuzatadi va logni keyinroq yuboradi (RPO> 0, past latentlik).
Kvorum (Raft/Paxos): koʻpchilik tugunlarga yozish; bitta log, avtomatik yetakchi.
Read-after-write: o’z yozuvlarini kafolatli o’qish (§ 5 ga qarang).

CAPni quyidagicha o’qing: tarmoq muammolarida siz tanqidiy operatsiyalar uchun muvofiqlikni (CP) yoki imkoniyatni (AP) tanlaysiz, ko’pincha turli yo’llardagi darajalarni birlashtirasiz.

3) Replikatsiya: variantlar va amaliyotlar

3. 1 Jismoniy va mantiqiy

Jismoniy (WAL/redo/binlog): blok jurnalga yaqin, oddiy va tezkor; gomogen topologiya/versiya bilan cheklangan.
Mantiqiy: satrlar/jadvallar darajasida DML/DDL oqimi; DWH/striming uchun qisman nusxalar, versiyalar orasidagi koʻchishlar, CDC imkonini beradi.

3. 2 Moslash va boshqarish

lag (vaqt/bayt/LSN) ni boshqaring.
Hot-standby feedback va uzoq so’rovlarni cheklang (VACUUM/kliningni to’xtatmaslik uchun).
MySQL uchun - GTID va Orchestrator; для PostgreSQL — Patroni/replication slots, synchronous_standby_names.

sql
-- on leader
ALTER SYSTEM SET synchronous_commit = 'on';
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (standby_a, standby_b)';
SELECT pg_reload_conf();

sql
SET GLOBAL enforce_gtid_consistency = ON;
SET GLOBAL gtid_mode = ON; -- restart
CHANGE MASTER TO MASTER_AUTO_POSITION=1;

3. 3 Topologiyalar

1 → N (yetakchi → replikalar) + kaskadlar (replika uzoqroq oqadi).
Multi-primary (active-active) - OLTPda qat’iy nizo-menejmentsiz qochish.
Quorum-klaster (Raft) - CockroachDB/Yugabyte/PG-Raft-ustavlar.

4) Read/Write Split va marshrutlash

Doimo yetakchi sifatida yozing; so’zlar bilan o’qing, lekin lag’ni hisobga oling.

1. Session stickiness: muvaffaqiyatli yozilgandan so’ng, mijoz’T’Δ davomida etakchini o’qiydi.

2. LSN/GTID-geyt: mijoz «Men LSN = X dan katta bo’lishni xohlamayman», deb xabar beradi, router LSN ≥ Xni replikaga yuboradi.

3. Stale-ok: soʻrovlarning bir qismi eskirgan maʼlumotlarga (kataloglar/lentalar) ruxsat beradi.

Asboblar: PgBouncer/Pgpool-II (Postgres), ProxySQL/MaxScale (MySQL), Vitess.

LSN-gate misoli:’pg _ current _ wal _ lsn ()’ni HTTP-xeder/kukga saqlang va routerdan’pg _ last _ wal _ replay _ lsn () ≥ LSN’nusxasini talab qiling.

5) Sharding strategiyasi

5. 1 Kalitni tanlash

• Hash’tenant _ id ’/’ user _ id’- teng, lekin range-skanerlardan mahrum qiladi.
• Vaqt boʻyicha Range/ID - time-series/arxiv uchun juda yaxshi, ammo xavf hot-shard.
• Consistent hashing - shardlarni qoʻshish/olib tashlashni soddalashtiradi.
• Directory/lookup jadvali moslashuvchan (har qanday algoritm), lekin yana bir jadval/kesh.

5. 2 Patternlar

Shared-nothing: har bir shard - alohida DB/klaster, ilova yo’nalishni biladi.
Middleware-sharding: Vitess (MySQL), Citus (Postgres), Proxy darajasi topologiyani yashiradi.
Federatsiya: maʼlumotlar domenlarini servislar boʻyicha ajratish (catalog, payments, auth).

5. 3 Kompozit kalitlar

’{tenant}: {entity}: {id}’ tugmasini ishlating va uni dastur va keshda saqlang. Для Postgres — hash partitioning + LIST/RANGE subpartition.

sql
CREATE TABLE orders (
tenant_id int,
id     bigint,
created_at timestamptz,
...,
PRIMARY KEY (tenant_id, id)
) PARTITION BY HASH (tenant_id);

CREATE TABLE orders_t0 PARTITION OF orders FOR VALUES WITH (MODULUS 16, REMAINDER 0);
--... t1..t15

6) Identifikatorlarni generatsiya qilish

Chardingda «issiq» monoton avtoinkrementlardan qoching.
Snowflake kabi 64-bit ID (time + region + shard + seq) yoki ULID/KSUID (monotonlik va taqsimlanish) dan foydalaning.
Для Postgres — sequence per shard; MySQL uchun - auto_increment_increment/offset (shard rahbarlaridagi turli ofsetlar).

7) Onlayn-peresardlash va migratsiya

Asosiy tamoyillar: ikki tomonlama yozuv (dual-write), idempotentlik, vaqtinchalik ikki tomonlama marshrutlash.

1. Yangi shard/klaster qoʻshing.

2. Dual-o’qishni yoqing.

3. Dual-write (ikkala sharda) ni yoqing, farqlarni aniqlang.

4. Tarixiy maʼlumotlarni (batchi, mantiqiy/CDC replikatsiyasi) bajaring.

5. «Haqiqat manbai» ni yangi shardga oʻtkazing; «quyruq» sinxronizatsiyasini qoldiring.

6. Eskisini oʻchiring.

Instrumentlar: Vitess Resharding, Citus move shards, pg_logical/pgoutput, Debezium (CDC), gh-ost/pt-online-schema-change (DDL blokirovkasiz).

8) Ko’p mintaqa va georaylash

Leader-follower per region: lokal o’qish, yozuv - global rahbar orqali (oddiy model, lekin cross-region RTT).
Multi-leader: ikkala hududda ham yozuv - mojaro-merjing (timestamp/versiya/CRDT) kerak.
True distributed SQL (Raft): CockroachDB/Yugabyte - maʼlumotlar mintaqaga yopishtirilgan, soʻrovlar mahalliy kvorumga oʻtadi.

• Pul/buyurtmalar - CP (kvorum/yetakchi), kataloglar/lentalar - AP (kesh, eventual).
• Har doim split-brain ehtimolida write fencing (noyob kalitlar/versiyalash) ni rejalashtiring.

9) Amaliyotda muvofiqlik

Read-your-writes: LSN/GTIDni «ushlagan» yetakchiga yoki nusxasiga.
Monotonic reads: oxirgi oʻqilgan LSN dan «katta emas».
Write-conflict control: `SELECT... FOR UPDATE’, versiyasi (’xmin ’/’ rowversion’), versiyasini tekshirgan holda UPSERT.
Idempotentlik: to’lov/hodisalarda idempotentlik kalitlari.

10) Kuzatish, SLO va alerta

Lag replik: vaqt (sek), LSN distance (bytes), seconds_behind_master (MySQL).
Majburiy qaytish/mojarolar, replikatsiya xatolari.
p95/p99 latency по route (read leader vs replica, write).
Throughput: TPS/locks/row-contended tables.
Bloat/VACUUM (PG), InnoDB buffer pool hit ratio (MySQL).
Dashbordlar: per-shard yuklamasi, «issiq» shardlar, kalitlarni taqsimlash.

11) Bekaplar, PITR va DR

PITR uchun to’liq backap + WAL/binlog (point-in-time recovery).
Boshqa mintaqada/bulutda saqlang, muntazam ravishda qayta tiklash testlarini o’tkazing.
Shardlar uchun - kelishilgan «kesma» (vaqtni muvofiqlashtirish/LSN) yoki tiklanishdagi aplikativ idempotentlik.
RPO/RTO ro’yxatga olingan va game-days-da sinovdan o’tkaziladi.

bash pg_basebackup -D/backups/base -X stream -C -S slot_replica_1 WAL archiving via archive_command or pgBackRest/Barman

12) Xavfsizlik va foydalanish

Proksiga VPC/ACL, mTLS bo’yicha segmentlash.
Eng kam huquqlar prinsipi bo’yicha rollar/grantlar; shard/rolga alohida foydalanuvchilar.
DDL/DCL auditi, «og’ir» so’rovlar uchun limitlar.
at rest (KMS) va tranzitda (TLS) shifrlash.
«Vahima tugmasi»: hodisa/tergov paytida global’READ ONLY’.

13) Asboblar va g’ishtlar

PostgreSQL: Patroni (HA), PgBouncer (pooling/RO-routing), repmgr, pgBackRest/Barman (бэкап), Citus (шардинг), pglogical/Logical Replication, pgbadger/pg_stat_statements.
MySQL: Orchestrator (topologiyalar/avto-failover), ProxySQL/MaxScale (marshrutizatsiya), Percona XtraBackup (backap), Group Replication/InnoDB Cluster, Vitess (sharding/resxarding).
Distributed SQL: CockroachDB, YugabyteDB (kvorum, o’rnatilgan sharding/geolokatsiya).
CDC: Debezium + Kafka/Pulsar/ETL.

14) Anti-patternlar

Avto-failoversiz va DR testlarsiz Single-primary.
«Sehrli» read-split lag → fantomik xatolar/shubhali xatolar hisobga olinmagan holda.
Sharding «sharding uchun»: vertikal skeyl/indeks/kesh o’rniga erta murakkablik.
Issiq diapazon (time-range) time-bucket/hash-salt → bitta shard eriydi.
OLTPda o’nlab shardlardan yuqori 2PC global tranzaksiya - yuqori p99 dumlari va tez-tez blokirovkalar.
Migratsiyalarda dual-write/dual-read yo’qligi → yo’qotish/rasinxron.
DDL prodda onlayn vositalarsiz va fich-bayroqlarsiz.

15) Joriy etish chek-varaqasi (0-60 kun)

0-15 kun

SLO DB, RPO/RTO belgilansin.
Replikatsiya, lag monitoringi, bazaviy bekaplar + PITR.
Router (PgBouncer/ProxySQL) va read-after-write siyosatini kiritish.

16-30 kun

Sharding strategiyasini tanlash, kalitlar va sxemalarni tasvirlash.
Vitess/Citus/CDC vositalarini tayyorlash.
«read-stale-ok» vs «strict» belgisi qo’yilgan servislar/jadvallar katalogi.

31-60 kun

Pilot-shard, dual-read va backfill dasturlarini ishga tushirish.
Game-day: etakchi, PITR dan tiklash, mintaqani o’zgartirish.
Issiq shard-kalitlar va notekis hisobotlarni avtomatlashtirish.

16) Etuklik metrikasi

Replica lag p95 <maqsadli (masalan, 500 ms) tanqidiy oʻqishlar uchun.
Muvaffaqiyatli DR-testlar ≥ 1/chorak (restore ≤ RTO, RPO ≤ yo’qotish).
Yuklamani shardlar boʻyicha taqsimlash: nomutanosiblik <20% QPS/ombor boʻyicha.
Strict-consistency so’rovlar ulushi, to’g "ri yo’naltirilgan, = 100%.
CP kafolatlarini talab qiladigan hodisalarda Zero-data-loss (pul/buyurtmalar).
To’xtovsiz, mos bayroq bilan onlayn DDL/migratsiya.

17) Retseptlar namunalari

sql
-- calculate bucket = hash (user_id)% 16, store (bucket, created_at)
PARTITION BY LIST (bucket) SUBPARTITION BY RANGE (created_at)

python lsn = db. leader_query("SELECT pg_current_wal_lsn()")
ctx. sticky_until = now()+5s ctx. min_lsn = lsn in the read router: select a replica with last_lsn> = ctx. min_lsn, otherwise the leader

json
{
"tables": {
"orders": { "column_vindexes": [{ "column": "tenant_id", "name": "hash" }] }
}
}

18) Xulosa

Sharding va replikatsiya - bu nafaqat texnika, balki jarayonlar: muvofiqlikni hisobga olgan holda marshrutlash, migratsiya intizomi (dual-write/read, backfill), muntazam DR-testlar va lag/issiq shardlarni kuzatish. Oddiy leader → replica + read-after-write bilan boshlang, so’ngra yuk profili talab qiladigan joyga sharding qo’shing. Tayyor platformalardan (Vitess/Citus/Distributed SQL) foydalaning va biznes-tanqidiy ma’lumotlarni CP rejimida saqlang - shunday qilib, baza butilka bo’yniga aylanmaydi va platformaning bashorat qilinadigan, elastik poydevoriga aylanadi.