Verilənlər bazasının şardinqi və replikasiyası

Verilənlər bazasının şardinqi və replikasiyası

1) Niyə lazımdır

• Bant genişliyi (üfüqi böyümə write QPS).
• Əlçatanlıq (sürətli failover, tək uğursuzluq nöqtəsi yoxdur).
• Məlumatların lokalizasiyası (multi-region, aşağı gecikmə).
• Səs-küylü qonşuların izolyasiyası (hot tenants/hot keys).

2) Əsas uyğunluq şərtləri və modelləri

Primary/Leader Replica/Follower: lider yazma, oxu - replikalar.
Sinxron replikasiya: N qovşaqlarına yazdıqdan sonra əməliyyatın təsdiqlənməsi (aşağı RPO, daha yüksək gecikmə).
Asinxron: lider kommiti düzəldir və log daha sonra göndərir (RPO> 0, aşağı gecikmə).
Kvorum (Raft/Paxos): əksər düyünlərə giriş; bir log, avtomatik lider.
Read-after-write: qeydlərinizi oxumaq üçün zəmanət (bax § 5).

CAP-ı belə oxuyuruq: şəbəkə problemləri zamanı kritik əməliyyatlar üçün uyğunluq (CP) və ya əlçatanlıq (AP) seçirsiniz, tez-tez müxtəlif yollarda səviyyələri birləşdirirsiniz.

3) Replikasiya: variantlar və təcrübələr

3. 1 Fiziki və məntiqi

Fiziki (WAL/redo/binlog): blok jurnalına yaxın, sadə və sürətli; homogen topologiya/versiya ilə məhdudlaşır.
Məntiq: sətir/cədvəl səviyyəsində DML/DDL axını; qismən replica imkan verir, versiyaları arasında miqrasiya, DWH/axını üçün CDC.

3. 2 Konfiqurasiya və idarəetmə

lag (vaxt/bayt/LSN) nəzarət.
Hot-standby feedback və uzun replika sorğularını məhdudlaşdırın (VACUUM/təmizləməni dayandırmamaq üçün).
MySQL üçün - GTID və Orchestrator; для PostgreSQL — Patroni/replication slots, synchronous_standby_names.

sql
-- на лидере
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; -- перезапуск
CHANGE MASTER TO MASTER_AUTO_POSITION=1;

3. 3 Topologiyalar

1 → N (lider → replikalar) + kaskadlar (replika daha axır).
Multi-primary (active-active) - ciddi münaqişə-menecment olmadan OLTP-də qaçmaq.
Quorum-klaster (Raft) - CockroachDB/Yugabyte/PG-Raft-əlavələr.

4) Read/Write Split və marşrutlaşdırma

Həmişə lider yazın; replications ilə oxuyun, lakin lag nəzərə.

1. Session stickiness: Uğurlu yazıdan sonra müştəri 'Δ T' ərzində liderdən oxuyur.

2. LSN/GTID-qapısı: Müştəri «Mən LSN = X-dən yaşlı deyiləm» deyir, marşrutlayıcı LSN ≥ X-in replikasına göndərir.

3. Stale-ok: Sorğuların bir hissəsi köhnəlmiş məlumatlara (kataloqlar/lentlər) imkan verir.

Alətlər: PgBouncer/Pgpool-II (Postgres), ProxySQL/MaxScale (MySQL), Vitess (şard marşrutu).

LSN-geyt nümunəsi (ideya): 'pg _ current _ wal _ lsn ()' HTTP-heder/kuku saxlayın və routerdən 'pg _ last _ wal _ replay _ lsn () ≥ LSN' -dən replika tələb edin.

5) Şardinq strategiyaları

5. 1 Açar seçimi

• Hash 'tenant _ id '/' user _ id' - bərabər, lakin range-skanlardan məhrum edir.
• Range/ID time-series/arxiv üçün əladır, lakin risk hot-shard.
• Consistent hashing - Şardların əlavə edilməsini/çıxarılmasını asanlaşdırır.
• Directory/lookup cədvəli - çevik (hər hansı bir alqoritm), lakin başqa bir cədvəl/cache.

5. 2 Nümunələr

Shared-nothing: Hər bir şard ayrı bir DB/klasterdir, proqram marşrutu bilir.
Middleware-charding: Vitess (MySQL), Citus (Postgres), Proxy-level topologiyanı gizlədir.
Federasiya: verilənlər domenlərinin xidmətlər üzrə bölünməsi (catalog, payments, auth).

5. 3 Kompozit açarlar

Açar məkanından istifadə edin: '{tenant}: {entity}: {id}' və bunu app və cache-də saxlayın. Для 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) ID Generation

Şardinqdə «isti» monoton avtomobil artımlarından çəkinin.
64-bit ID (time + region + shard + seq) və ya ULID/KSUID (monotonluq və paylanma) kimi Snowflake istifadə edin.
Для Postgres — sequence per shard; MySQL üçün - auto_increment_increment/offset (Şard liderlərində müxtəlif ofsetlər).

7) Online Perchard və Miqrasiya

Açar prinsiplər: ikiqat qeyd (dual-write), idempotentlik, müvəqqəti ikiqat marşrut.

1. Yeni bir şard/klaster əlavə edin.

2. Dual-read (tutarlılıq testi) daxil edin.

3. Dual-write (hər iki qarışıq) daxil edin, uyğunsuzluqları qeyd edin.

4. Tarixi məlumatların backfill (batches, logic replication/CDC) yerinə yetirin.

5. "Həqiqət mənbəyi 'ni yeni bir şarda keçirin; «quyruq» sinxronizasiyasını buraxın.

6. Köhnə söndürün.

Alətlər: Vitess Resharding, Citus move shards, pg_logical/pgoutput, Debezium (CDC), gh-ost/pt-online-schema-change (DDL kilidsiz).

8) Multi-region və geo-paylama

Leader-follower per region: yerli oxunmalar, qeydlər - qlobal lider vasitəsilə (sadə model, lakin cross-region RTT).
Multi-leader: Hər iki bölgədə qeyd - konflikt-mercing (timestamp/versiya/CRDT) lazımdır.
True distributed SQL (Raft): CockroachDB/Yugabyte - bölgəyə «yapışdırılmış» məlumatlar, sorğular yerli kvoruma gedir.

• Pul/sifarişlər - CP (kvorum/lider), kataloqlar/lentlər - AP (cache, eventual).
• Həmişə mümkün split-brain ilə write fencing (unikal açarları/versiyası) planlaşdırın.

9) Praktikada uyğunluq

Read-your-writes: LSN/GTID-i «tutmuş» lider və ya replika.
Monotonic reads: son oxunan LSN «yaşlı deyil».
Write-conflict control: `SELECT... FOR UPDATE ', versiyalar (' xmin '/' rowversion '), versiyanın yoxlanılması ilə UPSERT.
İdempotentlik: ödənişlərdə/hadisələrdə idempotentlik açarları.

10) Müşahidə, SLO və alertlər

Lag replika: vaxt (san), LSN distance (bytes), seconds_behind_master (MySQL).
Məcburi geri çəkilmələr/münaqişələr, replikasiya səhvləri.
p95/p99 latency по route (read leader vs replica, write).
Throughput: TPS/locks/row-contended tables.
Bloat/VACUUM (PG), InnoDB buffer pool hit ratio (MySQL).
Dashboard: per-shard yük, «isti» şarlar, açar paylanması.

11) Backup, PITR və DR

PITR (point-in-time recovery) üçün tam arxa + WAL/binlog.
Başqa bir bölgədə/buludda saxlayın, mütəmadi olaraq bərpa testləri aparın.
Şardlar üçün - razılaşdırılmış «kəsik» (vaxt koordinasiyası/LSN) və ya bərpa zamanı aplikativ idempotentlik.
RPO/RTO-lar game-days-də təyin olunur və sınaqdan keçirilir.

bash pg_basebackup -D /backups/base -X stream -C -S slot_replica_1 архивация WAL через archive_command или pgBackRest/Barman

12) Təhlükəsizlik və giriş

VPC/ACL, mTLS proxy seqmentasiyası.
Minimal hüquqlar prinsipi üzrə rollar/qrantlar; şard/rol üçün fərdi istifadəçilər.
DDL/DCL auditi, replikalarda «ağır» sorğulara limitlər.
at rest (KMS) və tranzit (TLS) şifrələmə.
«Panika düyməsi»: hadisə/istintaq zamanı qlobal 'READ ONLY'.

13) Alətlər və kərpiclər

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 (marşrutlaşdırma), Percona XtraBackup (backap), Group Replication/InnoDB Cluster, Vitess (charding/resharding).
Distributed SQL: CockroachDB, YugabyteDB (kvorum, daxili şardinq/geolokasiya).
CDC: Debezium + Kafka/Pulsar/ETL.

14) Anti-nümunələr

auto-failover və DR testləri olmadan Single-primary.
«Magic» read-split lag nəzərə alınmadan → Fantom səhvləri/şübhəli səhvlər.
Charding «charding üçün»: şaquli skeyl/indekslər/cache əvəzinə vaxtından əvvəl çətinlik.
time-bucket/hash-salt → bir şard əriyir olmadan isti range (time-range).
ALTP-də onlarla şardın üstündə qlobal əməliyyat 2PC - yüksək p99 quyruqları və tez-tez kilidləmə.
Miqrasiyalarda dual-write/dual-read → itki/rasinxron yoxdur.
DDL onlayn alətsiz və fice-flags uyğunluğu olmadan.

15) Giriş çek siyahısı (0-60 gün)

0-15 gün

SLO DB, RPO/RTO müəyyən edin.
Replikasiyanı, lag monitorinqini, əsas backapları + PITR-i daxil edin.
Router (PgBouncer/ProxySQL) və read-after-write siyasətini daxil edin.

16-30 gün

Charding strategiyasını seçin, açarları və sxemləri təsvir edin.
Vitess/Citus/CDC (Vitess/Citus/CDC) alətlərini hazırlayın.
«read-stale-ok» vs «strict» işarəsi olan xidmətlər/cədvəllər kataloqu.

31-60 gün

Pilot-shard, dual-read və backfill başlayın.
Game-day: lider failover, PITR bərpa, region keçid.
Qaynar şard açarları və qeyri-bərabər hesabatları avtomatlaşdırın.

16) Yetkinlik metrikası

Replica lag p95 <kritik oxunmalar üçün hədəf (məsələn, 500 ms).
Uğurlu DR testləri ≥ 1/rüb (bərpa ≤ RTO, ≤ RPO itkisi).
Yük paylanması: <20% QPS/saxlama balanssızlığı.
strict-consistency ilə sorğuların payı, düzgün marşrutlaşdırılmış, = 100%.
CP zəmanəti tələb edən hadisələrdə Zero-data-loss (pul/sifariş).
Online DDL/fasiləsiz miqrasiya, uyğunluq bayraqları ilə.

17) Resept nümunələri

sql
-- вычисляйте bucket = hash(user_id) % 16, храните (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 в роутере чтений: выбираем реплику с last_lsn >= ctx.min_lsn, иначе лидер

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

18) Nəticə

Sharding və replikasiya yalnız texnika deyil, həm də proseslərdir: uyğunluq nəzərə alınmaqla marşrutlaşdırma, miqrasiya intizamı (dual-write/read, backfill), müntəzəm DR testləri və lag/isti şardların müşahidə edilməsi. Sadə bir lider → replica + read-after-write ilə başlayın, sonra yükləmə profilinin həqiqətən tələb olunduğu yerdə bir şərt əlavə edin. Hazır platformalardan (Vitess/Citus/Distributed SQL) istifadə edin və biznes kritik məlumatları CP rejimində saxlayın - belə ki, baza şüşə boynu olmağı dayandıracaq və platformanın proqnozlaşdırıla bilən, elastik təməli olacaq.