Дерекқорды шардингтеу және репликалау

Дерекқорды шардингтеу және репликалау

1) Бұл не үшін қажет

• Өткізу қабілеті (write QPS көлденең өсуі).
• Қол жетімділік (жылдам failover, бірыңғай істен шығу нүктесінің болмауы).
• Деректерді оқшаулау (мульти-өңір, төмен жасырындылық).
• Шулы көршілерді оқшаулау (hot tenants/hot keys).

2) Келісудің базалық терминдері мен модельдері

Primary/Leader Replica/Follower: көшбасшыда жазу, репликаларда оқу.
Синхронды репликация: N тораптарға жазылғаннан кейін транзакцияны растау (төмен RPO, жоғары жасырындылық).
Асинхронды: көшбасшы коммитті тіркейді және логты кейінірек жібереді (RPO> 0, төмен латенттілік).
Кворумды (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
-- на лидере
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 Топологиялар

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-сканерден айырады.
• Уақыт бойынша Range/ID - time-series/мұрағат үшін өте жақсы, бірақ тәуекел hot-shard.
• Consistent hashing - шардтарды қосуды/жоюды жеңілдетеді.
• Directory/lookup кестесі - икемді (кез келген алгоритм), бірақ тағы бір кесте/кэш.

5. 2 Үлгілер

Shared-nothing: әрбір шард - жеке БД/кластер, қосымша бағыттауды біледі.
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) Идентификаторларды генерациялау

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

7) Онлайн қайта барлау және көші-қон

Түйінді қағидаттар: қосарлы жазба (dual-write), теңсіздік, уақытша қосарлы бағыттау.

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

2. Қосыңыз dual-read (тығыздығын тексеру).

3. Dual-write бағдарламасын қосыңыз, айырмашылықтарды белгілеңіз.

4. Тарихи деректерді backfill (батчи, логикалық/CDC репликасын) орындаңыз.

5. «Шындық көзін» жаңа шардқа ауыстырыңыз; «артқы» үндестіруді қалдырыңыз.

6. Ескісін өшіріңіз.

Құралдар: Vitess Resharding, Citus move shards, pg_logical/pgoutput, Debezium (CDC), gh-ost/pt-online-schema-change (DDL бұғаттаусыз).

8) Мульти-өңір және геораспределение

Leader-follower per region: жергілікті оқулар, жазба - жаһандық көшбасшы арқылы (қарапайым үлгі, бірақ cross-region RTT).
Multi-leader: екі өңірдегі жазба - жанжал-мерджинг (timestamp/нұсқа/CRDT) қажет.
True distributed SQL (Raft): CockroachDB/Yugabyte - деректер аймаққа «жапсырылған», сұрау салулар жергілікті кворумға өтеді.

• Ақша/тапсырыстар - CP (кворум/көшбасшы), каталогтар/таспалар - AP (кэш, eventual).
• Мүмкін split-brain кезінде әрқашан write fencing (бірегей кілттер/нұсқалау) жоспарлаңыз.

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).
Дашбордтар: per-shard жүктеме, «ыстық» шардар, кілттерді бөлу.

11) Бэкаптар, PITR және DR

PITR (point-in-time recovery) үшін толық бэкап + WAL/binlog.
Басқа аймақта/бұлтта сақтаңыз, үнемі restore-тесттер жасаңыз.
Шардтар үшін - келісілген «кесу» (уақытты үйлестіру/LSN) немесе қалпына келтіру кезіндегі аппликативтік теңсіздік.
RPO/RTO game-days-те жазылған және тестіленеді.

bash pg_basebackup -D /backups/base -X stream -C -S slot_replica_1 архивация WAL через archive_command или 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 (топологиялар/авто-failover), ProxySQL/MaxScale (маршруттау), Percona XtraBackup (бэкап), Group Replication/InnoDB Cluster, Vitess (шардинг/ресхардинг).
Distributed SQL: CockroachDB, YugabyteDB (кворум, орнатылған шардинг/геолокация).
CDC: Debezium + Kafka/Pulsar оқиғалар үшін/ETL.

14) Қарсы үлгілер

Авто-failover және DR тестісіз Single-primary.
«Сиқырлы» read-split lag есептемегенде → фантомдық қателер/күдікті қателер.
Шардинг «шардинг үшін»: тік скейлдің/индекстердің/кэштің орнына мерзімінен бұрын күрделендіру.
Ыстық диапазон (time-range) уақыт-bucket/hash-salt → бір шард ереді.
Жаһандық транзакция OLTP-дегі ондаған шардтың үстінен 2PC - p99 жоғары қалдықтары және жиі бұғаттау.
Көші-қон кезінде dual-write/dual-read болмауы → жоғалту/рассинхрон.
DDL онлайн-құралдарсыз және сыйысымдылық фич-жалаушаларсыз.

15) Енгізу чек-парағы (0-60 күн)

0-15 күн

SLO ДҚ, RPO/RTO анықтау.
Репликацияны, lag мониторингін, базалық бэкаптарды + PITR қосу.
Роутерді (PgBouncer/ProxySQL) және read-after-write саясатын енгізу.

16-30 күн

Шардинг стратегиясын таңдау, кілттер мен схемаларды сипаттау.
Қайта зарядтау құралдарын дайындау (Vitess/Citus/CDC).
«read-stale-ok» vs «strict» белгісі бар сервистер/кестелер каталогы.

31-60 күн

Pilot-шард, dual-read және backfill бағдарламаларын іске қосу.
Game-day: көшбасшының failover, PITR қалпына келтіру, аймақты ауыстыру.
Ыстық шард-кілттер және біркелкі еместігі бойынша есептерді автоматтандыру.

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

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

17) Рецепт үлгілері

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) Қорытынды

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