Шардинг жана репликациялоо

Шардинг жана маалымат базасын репликациялоо

1) Эмне үчүн керек

• кубаттуулугу (горизонталдуу өсүш write QPS).
• Жеткиликтүүлүк (fast failover, бирдиктүү мүчүлүштүктүн жоктугу).
• Маалыматтарды локалдаштыруу (көп аймак, төмөн жашыруун).
• Ызы-чуу кошуналарды изоляциялоо (hot tenants/hot keys).

2) Негизги терминдер жана шайкештик моделдери

Primary/Leader Replica/Follower: лидер жазуу, окуу - репликалар боюнча.
Синхрондуу репликация: транзакцияны N түйүндөрүнө жазгандан кийин ырастоо (төмөн RPO, жогорку латенттүүлүк).
Асинхрондук: Лидер коммитти оңдоп, журналды кийинчерээк жөнөтөт (RPO> 0, төмөн латенттүүлүк).
Quorum (Raft/Paxos): көпчүлүк түйүндөр боюнча жазуу; бир журнал, автоматтык лидер.
Read-after-write: кепилденген окуу жазуулар (кара § 5).

Биз CAPди төмөнкүдөй окуйбуз: тармак көйгөйлөрүндө сиз критикалык операциялар үчүн ырааттуулукту (CP) же жеткиликтүүлүктү (AP) тандайсыз, көбүнчө ар кандай жолдордо деңгээлдерди айкалыштырасыз.

3) Репликация: варианттар жана практикалар

3. 1 Физикалык жана логикалык

Физикалык (WAL/redo/binlog): блоктук журналга жакын, жөнөкөй жана тез; бир тектүү топология/версия менен чектелген.
Логикалык: саптар/таблицалар деңгээлинде DML/DDL агымы; жарым-жартылай реплика берет, котормолордун ортосунда көчүрүү, DWH/агымы үчүн CDC.

3. 2 орнотуу жана башкаруу

lag контролдоо (убакыт/байт/LSN).
Hot-standby feedback жана репликалар боюнча узак суроо-талаптарды чектөө (VACUUM/тазалоо токтотуу үчүн эмес).
MySQL үчүн - GTID жана 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 Топология

1 → N (лидер → реплика) + каскаддар (реплика агат).
Multi-primary (active-active) - катуу чыр-менеджмент жок OLTP алыс.
Quorum-кластер (Raft) - CockroachDB/Yugabyte/PG-Raft-надстройка.

4) Read/Write Split жана багыттоо

Дайыма лидерге жазыңыз; сөздөрдү окуп, бирок эске lag.

1. Session stickiness: ийгиликтүү жазуудан кийин кардар 'Δ T' ичинде лидер менен окуйт.

2. LSN/GTID-дарбазасы: кардар мындай деди: "Мен LSN = X улгайган эмес келет", роутер LSN ≥ X көчүрмөсүн жөнөтөт.

3. Stale-ok: суроо-талаптардын бир бөлүгү эскирген маалыматтарды (каталогдор/тасмалар) жол берет.

Инструменттер: PgBouncer/Pgpool-II (Postgres), ProxySQL/MaxScale (MySQL), Vitess (шард багыттоо).

LSN-гейт мисалы (идея): 'pg _ current _ wal _ lsn ()' HTTP-хедер/куку сактоо жана 'pg _ last _ wal _ replay _ lsn () менен роутерден реплика талап ≥ LSN'.

5) Шардинг стратегиялары

5. 1 Ачкычты тандоо

• Hash 'tenant _ id '/' user _ id' - бирдей, бирок range-сканерлерди ажыратат.
• Убакыт/ID Range - убакыт сериясы/архив үчүн жакшы, бирок тобокелдик hot-shard.
• Consistent hashing - кошуу/алып салууну жөнөкөйлөтөт.
• Directory/lookup-стол - ийкемдүү (ар кандай алгоритм), бирок дагы бир стол/кэш.

5. 2 Үлгүлөр

Shared-nothing: ар бир шард - өзүнчө DD/кластер, колдонмо багытын билет.
Middleware-шардинг: Vitess (MySQL), Citus (Postgres), Proxy-деңгээл топологиясын жашырат.
Киргизия: кызмат боюнча маалымат домендерди бөлүштүрүү (catalog, payments, auth).

5. 3 композиттик ачкычтар

'{tenant}: {entity}: {id}' деген ачкыч мейкиндигин колдонуңуз жана аны колдонмодо жана кэште сактаңыз. Для 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) Идентификаторлорду генерациялоо

Шардингде "ысык" монотондук автоинкременттерден качыңыз.
Snowflake окшош 64-бит ID (убакыт + аймак + shard + seq) же ULID/KSUID (монотондук жана бөлүштүрүү) колдонуу.
Для Postgres — sequence per shard; MySQL үчүн - auto_increment_increment/offset (шардалардын лидерлериндеги ар кандай оффсеттер).

7) Онлайн кайра тактоо жана миграция

Негизги принциптер: кош жазуу (кош жазуу), демпотенттик, убактылуу кош багыттоо.

1. Жаңы шард/кластер кошуу.

2. Кош-окуу (консистенттүүлүк текшерүү) кирет.

3. Кош-write (эки экиге тең) киргизип, айырмачылыктарды жазыңыз.

4. Backfill тарыхый маалыматтарды (батчи, логикалык репликация/CDC) аткаруу.

5. "Чындык булагын" жаңы шардга которуңуз; "куйруктуу" синхрондоштурууну калтырыңыз.

6. эски өчүрүү.

Куралдар: Vitess Resharding, Citus move shards, pg_logical/pgoutput, Debezium (CDC), gh-ost/pt-online-schema-change (DDL кулпусу жок).

8) Көп аймак жана гео бөлүштүрүү

Лидер-follower per аймак: жергиликтүү окуулар, жазуу - дүйнөлүк лидер аркылуу (жөнөкөй модель, бирок cross-аймак RTT).
Multi-лидер: эки региондо жазуу - чыр-мерджинг (timestamp/версия/CRDT) керек.
True Distributed SQL (Raft): CockroachDB/Yugabyte - маалыматтар аймакка "чапталган", суроолор жергиликтүү кворумга барат.

• Акча/буйрутмалар - CP (кворум/лидер), каталогдор/ленталар - AP (кэш, eventual).
• Ар дайым пландаштыруу write fencing (уникалдуу ачкычтар/чыгаруу) мүмкүн split-brain.

9) иш жүзүндө ырааттуулук

Read-your-writes: лидер же реплика, "кууп" LSN/GTID.
Monotonic reads: "улуу эмес" акыркы окулган LSN.
Write-conflict control: `SELECT... FOR UPDATE ', версиясы (' xmin '/' rowversion '), версиясын текшерүү менен UPSERT.
Демпотенттүүлүк: төлөмдөр/окуялар боюнча демпотенттиктин ачкычтары.

10) байкоо, SLO жана Алерт

Лаг реплика: убакыт (сек), LSN distance (bytes), seconds_behind_master (MySQL).
Аргасыз артка чегинүү/чыр-чатактар, репликация каталары.
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 жүк, "ысык" шарлар, ачкычтарды бөлүштүрүү.

11) Backup, PITR жана DR

Толук backup + WAL/binlog үчүн PITR (пункту-in-time recovery).
Башка аймакта/булутта сактаңыз, дайыма калыбына келтирүү тесттерин жасаңыз.
Шардалар үчүн - макулдашылган "кесүү" (убакытты координациялоо/LSN) же калыбына келтирүүдөгү аппликативдик идемпотенттүүлүк.
RPO/RTO катталган жана game-days сыналган.

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

12) Коопсуздук жана жетүү

VPC/ACL, mTLS боюнча сегментация прокси.
Минималдуу укуктар принциби боюнча ролдор/гранттар; жеке колдонуучулар/ролу.
Аудит DDL/DCL, репликалар боюнча "оор" суроо-чектер.
Транскрипция at rest (KMS) жана транзит (TLS).
"Паника баскычы": окуя/тергөө учурунда глобалдык 'READ ONLY'.

13) Аспаптар жана кирпичтер

PostgreSQL: Patroni (HA), PgBouncer (pooling/RO-routing), repmgr, pgBackRest/Barman (бэкап), Citus (шардинг), pglogical/Logical Replication, pgbadger/pg_stat_statements.
MySQL: Orchestrator (топология/auto-failover), ProxySQL/MaxScale (багыттоо), Percona XtraBackup (backap), Group Replication/InnoDB Cluster, Vitess (sharding/resharding).
Distributed SQL: CockroachDB, YugabyteDB (кворум, орнотулган шардинг/геолокация).
CDC: Debezium + Kafka/Pulsar/ETL.

14) Анти-үлгүлөрү

Single-primary auto-failover жок жана DR тесттери жок.
"Magic" read-split эске албаганда lag → phantom каталар/шектүү каталар.
Charding "charding үчүн": тик скейлдин/индекстердин/кэштин ордуна эрте татаалдашуу.
Hot Range (time-range) жок time-bucket/hash-salt → бир шард эрийт.
АЛТПда ондогон 2PC үстүндөгү глобалдык транзакция - жогорку p99 куйруктары жана тез-тез бөгөттөөлөр.
Жок dual-write/dual-окуп көчүрүү → жоготуу/Рассинхрон.
DDL онлайн куралдары жок жана шайкештик желектери жок.

15) Чек-тизме киргизүү (0-60 күн)

0-15 күн

SLO DD, RPO/RTO аныктоо.
Репликация, lag мониторинг, негизги backaps + PITR кирет.
Роутерди (PgBouncer/ProxySQL) жана read-after-write саясатын киргизүү.

16-30 күн

Charding стратегиясын тандоо, ачкычтарды жана схемаларды сүрөттөө.
(Vitess/Citus/CDC).
"read-stale-ok" vs "strict" деген белги коюлган кызматтардын/таблицалардын каталогу.

31-60 күн

Pilot-shard, dual-read жана backfill баштоо.
Game-day: лидер failover, PITR калыбына келтирүү, аймакты өзгөртүү.
Ысык ачкычтар жана бирдей эместиктер боюнча отчетторду автоматташтыруу.

16) Жетилүү метрикасы

Replica lag p95 <максаттуу (мисалы, 500 ms) сын окуу үчүн.
Ийгиликтүү DR тесттер ≥ 1/чейрек (калыбына келтирүү ≤ RTO, жоготуу ≤ RPO).
жүк бөлүштүрүү: дисбаланс <20% QPS/сактоо боюнча.
strict-consistency менен суроо үлүшү, туура багытталган, = 100%.
CP кепилдиктерин талап кылган окуяларда Zero-data-loss (акча/буйрутмалар).
Онлайн DDL/токтоосуз миграция, шайкештик желектери менен.

17) Рецепт мисалдары

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) Корутунду

Шардинг жана репликация - бул техника гана эмес, ошондой эле процесстер: ырааттуулукту эске алуу менен багыттоо, миграциянын дисциплинасы (dual-write/read, backfill), үзгүлтүксүз DR тесттери жана lag/ысык шардаларды байкоо. Жөнөкөй leader → replica + read-after-write менен баштап, андан кийин жүктөө профилин талап кылган жерге шардана кошуңуз. Даяр платформаларды колдонуңуз (Vitess/Citus/Distributed SQL) жана бизнес-критикалык маалыматтарды CP режиминде сактаңыз - ошентип, база бөтөлкө оозу болбой калат жана платформанын болжолдуу, ийкемдүү пайдубалына айланат.