Sharding და მონაცემთა ბაზის რეპლიკაცია

Sharding და მონაცემთა ბაზის რეპლიკაცია

1) რატომ არის ეს აუცილებელი?

• გამტარუნარიანობა (ჰორიზონტალური ზრდა write QPS).
• წვდომა (სწრაფი failover, ერთი უკმარისობის წერტილის არარსებობა).
• მონაცემთა ლოკალიზაცია (მულტფილმის რეგიონი, დაბალი ლატენტობა).
• ხმაურიანი მეზობლების იზოლაცია (ცხელი tenants/hot keys).

2) ძირითადი ტერმინები და თანმიმდევრობის მოდელები

Primary/Leader Replica/Follower: ჩანაწერი ლიდერზე, კითხვა რეპლიკებზე.
სინქრონული რეპლიკაცია: გარიგების დადასტურება N კვანძებზე ჩაწერის შემდეგ (დაბალი RPO, ლატენტობის ზემოთ).
ასინქრონული: ლიდერი აფიქსირებს კომუნას და მოგვიანებით აგზავნის ლოგს (RPO> 0, დაბალი ლატენტობა).
Quoromnaya (Raft/Paxos): ჩაწერა უმეტეს კვანძებზე; ერთი ჟურნალი, ავტომატური ლიდერი.
Read-after-write: გარანტირებული კითხვა მისი ჩანაწერებისთვის (იხ. § 5).

CAP გაყიდვაში შემდეგნაირად ვკითხულობთ: ქსელის პრობლემებით, თქვენ ირჩევთ კოორდინაციას (CP) ან წვდომას (AP) კრიტიკულ ოპერაციებზე, ხშირად აერთიანებთ დონეს სხვადასხვა გზაზე.

3) რეპლიკაცია: ვარიანტები და პრაქტიკა

3. 1 ფიზიკური და ლოგიკური

ფიზიკური (WAL/redo/binlog): ბლოკის ჟურნალთან უფრო ახლოს, მარტივი და სწრაფი; შემოიფარგლება ჰომოგენური ტოპოლოგიით/ვერსიით.
ლოგიკური: DML/DDL ნაკადი სტრიქონების/ცხრილების დონეზე; საშუალებას გაძლევთ ნაწილობრივ შენიშვნები, მიგრაცია ვერსიებს შორის, CDC DWH/ნაკადისთვის.

3. 2 კონფიგურაცია და კონტროლი

აკონტროლეთ lag (დრო/ბაიტი/LSN).
შეზღუდეთ ცხელი სტენდები და გრძელი რეპლიკების მოთხოვნები (ისე, რომ არ შეაჩეროთ 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 (აქტიური) - თავიდან აიცილოთ OLTP მკაცრი კონფლიქტის მართვის გარეშე.
Érum კასეტა (რაფტი) - CockroachDB/Yugabyte/PG-Raft სუპერსტრუქტურები.

4) Read/Write Split და მარშრუტიზაცია

ყოველთვის დაწერე ლიდერი; წაიკითხეთ შენიშვნებიდან, მაგრამ გაითვალისწინეთ lag.

1. Session Stickiness: წარმატებული ჩაწერის შემდეგ, კლიენტი ლიდერს კითხულობს 'OST' - ში.

2. LSN/GTID კარიბჭე: კლიენტი აცნობებს „მე არ მინდა მოხუცი LSN = X“, როუტერი აგზავნის რეპლიკზე, რომლის LSN-X- ს.

3. Stale-ok: ზოგიერთი მოთხოვნა საშუალებას იძლევა მოძველებული მონაცემები (დირექტორიები/ფირები).

ინსტრუმენტები: PgBouncer/Pgpool-II (Postgres), ProxySQL/MaxScale (MySQL), Vitess (ხარის მარშრუტი).

LSN კარიბჭის მაგალითი (იდეა): შეინარჩუნეთ 'pg _ current _ wal _ lsn ()' 'HTTP Heder/cook- ში და მოითხოვეთ რეპლიკა' pg _ last _ wal _ replay _ lsn () Router- დან.

5) შარდინგის სტრატეგია

5. 1 გასაღები

• Hash 'tenant _ id '/' user _ id' - თანაბრად, მაგრამ ართმევს range სკანებს.
• Range დროულად/ID შესანიშნავია დროის სერიის/არქივისთვის, მაგრამ ცხელი შუქის რისკი.
• Consistent hashing - ამარტივებს ხუმრობის დამატებას/მოცილებას.
• ინდიკატორი/lookup ცხრილი არის მოქნილი (ნებისმიერი ალგორითმი), მაგრამ კიდევ ერთი ცხრილი/ქეში.

5. 2 შაბლონები

Shared-nothing: თითოეული საშინელება არის ცალკეული BD/კასეტა, აპლიკაციამ იცის მარშრუტიზაცია.
Middleware sharding: Vitess (MySQL), Citus (Postgres), Proxy დონე მალავს ტოპოლოგიას.
ფედერაცია: მონაცემთა დომენების გამიჯვნა სერვისებზე (კატალოგი, პაიმენტები, აუტი).

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 (დრო + region + shard + seq) ან ULID/KSUID (ერთფეროვნება და განაწილება).
Для Postgres — sequence per shard; MySQL- სთვის - auto _ increment _ increment/offset (სხვადასხვა ოფსეტები შარდების ლიდერებზე).

7) ონლაინ გადაკეთება და მიგრაცია

საკვანძო პრინციპები: ორმაგი ჩაწერა, იდემპოტენტურობა, დროებითი ორმაგი მარშრუტი.

1. დაამატეთ ახალი ხიბლი/კასეტა.

2. ჩართეთ dul read (თანმიმდევრულობის შემოწმება).

3. ჩართეთ ორმაგი write (ორივე საშინელებაში), დააფიქსირეთ განსხვავებები.

4. დააკვირდით ისტორიულ მონაცემებს (ბრძოლები, ლოგიკური რეპლიკაცია/CDC).

5. გადაიტანეთ „სიმართლის წყარო“ ახალ ხიბლში; დატოვეთ „კუდის“ სინქრონიზაცია.

6. გამორთეთ ძველი.

ინსტრუმენტები: Vitess Resharding, Citus move shards, pg _ logical/pgoutput, Debezium (CDC), gh-ost/pt-online-schema-chanananage (DDDDd).

8) მულტფილმის რეგიონი და განაწილება

Leader-follower per region: ადგილობრივი კითხვები, ჩაწერა - გლობალური ლიდერის მეშვეობით (მარტივი მოდელი, მაგრამ cross-region RTT).
Multi-leader: ჩანაწერი ორივე რეგიონში - საჭიროა კონფლიქტი-მერჯინგი (Timestamp/ვერსია/CRDT).
True distributed SQL (Raft): CockroachDB/Yugabyte - მონაცემები „მიბმული“ რეგიონში, მოთხოვნები მიდის ადგილობრივ კვორუმში.

• ფული/შეკვეთები - CP (კვორუმი/ლიდერი), კატალოგები/ფირები - AP (ქეში, ღონისძიება).
• ყოველთვის დაგეგმეთ write fencing (უნიკალური გასაღებები/ვერსია) შესაძლო split-brain.

9) შესაბამისობა პრაქტიკაში

Read your-writes: ლიდერი ან შენიშვნა, რომელიც LSN/GTID „დაიჭირა“.
Monotonic reads: LSN- ის ბოლო წაკითხული „არ არის უფრო ძველი“.
Write-conflict control: `SELECT... განახლება ', ვერსიები (' xmin '/' rowversion '), UPSERT ვერსიის შემოწმებით.
Idempotence: idempotent- ის გასაღებები გადახდაზე/მოვლენებზე.

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).
Dashboards: per-shard დატვირთვა, „ცხელი“ shards, გასაღებების განაწილება.

11) Bacaps, PITR და DR

სრული bacap + WAL/binlog PITR- ისთვის (წერტილოვანი დროის ჩანაწერები).
შეინახეთ სხვა რეგიონში/ღრუბელში, რეგულარულად გააკეთეთ restore ტესტები.
შარდისთვის - შეთანხმებული „გაჭრა“ (დროის კოორდინაცია/LSN) ან აპლიკაციური იდემპოტენტობა აღდგენის დროს.
RPO/RTO არის რეგისტრირებული და ტესტირებული თამაშის დღეებში.

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

12) უსაფრთხოება და წვდომა

VPC/ACL სეგმენტი, mTLS მარიონეტული.
როლები/გრანტები მინიმალური უფლებების საფუძველზე; ინდივიდუალური მომხმარებლები shard/როლზე.
DDL/DCL აუდიტი, რეპლიკების „მძიმე“ მოთხოვნის შეზღუდვები.
დაშიფვრა (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 (bacap), Replicacecititititition/ition/ion-ion-ion-ion-ion-ion-ion-ion-ion-ist-Inde-ive, ve, ve, ve, ve, vResharding).
Distributed SQL: CockroachDB, YugabyteDB (კვორუმი, ჩაშენებული შარდინგი/გეოლოკაცია).
CDC: Debezium + Kafka/Pulsar მოვლენებისთვის/ETL.

14) ანტი შაბლონები

Single-primary გარეშე მანქანა-failover და DR ტესტების გარეშე.
„ჯადოსნური“ read-split, ლაგის გამოკლებით, არის ფანტომური შეცდომები/საეჭვო შეცდომები.
შარდინგი „შარდინგის გულისთვის“: ნაადრევი გართულება ვერტიკალური სკეიტის/ინდექსების/ქეშის ნაცვლად.
ცხელი დიაპაზონი (დროის დიაპაზონი) time-bucket/hash-salt გარეშე - ერთი საშინელება დნება.
OLTP- ში ათეულობით ხარის თავზე 2PC გლობალური გარიგება არის მაღალი p99 კუდი და ხშირი დაბლოკვა.
მიგრაციის დროს ორმაგი write/dul-read- ის არარსებობა არის ზარალი/რასინქრონი.
DDL გაყიდვაში, ონლაინ ინსტრუმენტების გარეშე და თავსებადობის ჩარტების გარეშე.

15) განხორციელების სიის სია (0-60 დღე)

0-15 დღე

განსაზღვრეთ SLO BD, RPO/RTO.
ჩართეთ რეპლიკაცია, ლაგის მონიტორინგი, საბაზო ჩანთები + PITR.
შეიყვანეთ როუტერი (PgBouncer/ProxySQL) და read-after-write პოლიტიკა.

16-30 დღე

შეარჩიეთ შარდინგის სტრატეგია, აღწერეთ გასაღებები და სქემები.
გადამუშავების ინსტრუმენტების მომზადება (Vitess/Citus/CDC).
სერვისების/ცხრილების კატალოგი, რომელზეც აღინიშნება „read-stale-ok“ vs „strict“.

31-60 დღე

დაიწყეთ pilot shard, dul read და backfill.
თამაშის დღე: failover ლიდერი, აღდგენა PITR- დან, რეგიონის შეცვლა.
მოხსენებების ავტომატიზაცია ცხელი ხუჭუჭა გასაღებებზე და არათანაბარი.

16) სიმწიფის მეტრიკა

კრიტიკული კითხვებისთვის Replica lag p95 <სამიზნე (მაგალითად, 500 მმ).
წარმატებული DR ტესტები - 1/კვარტალი (Restore - RTO, RPO- ს დაკარგვა).
დატვირთვის განაწილება შარდში: დისბალანსი <20% QPS/შენახვის ობიექტში.
მოთხოვნის წილი სტრატეგიული კონსულტაციით, სწორად მარშრუტიზებული, = 100%.
Zero-data-loss ინციდენტებში, რომლებიც მოითხოვს CP გარანტიებს (ფული/შეკვეთები).
ონლაინ 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) დასკვნა

შარდინგი და რეპლიკაცია არა მხოლოდ ტექნოლოგია, არამედ პროცესებია: მარშრუტიზაცია თანმიმდევრულობის გათვალისწინებით, მიგრაციის დისციპლინა (ორმაგი-write/read, backfill), რეგულარული DR ტესტები და lag/ცხელი ხუმრობების დაკვირვება. დაიწყეთ მარტივი leader - replica + read-after-write, შემდეგ დაამატეთ sharding, სადაც მას ნამდვილად სჭირდება დატვირთვის პროფილი. გამოიყენეთ მზა პლატფორმები (Vitess/Citus/Distributed SQL) და შეინარჩუნეთ ბიზნესის კრიტიკული მონაცემები CP რეჟიმში - ასე რომ, ბაზა შეწყვეტს ბოთლის კისერს და გახდება პლატფორმის პროგნოზირებადი, ელასტიური საფუძველი.