Αποθήκευση και αντιγραφή βάσης δεδομένων

Αποθήκευση και αντιγραφή βάσης δεδομένων

1) Γιατί το χρειάζεστε

• Απόδοση (γράψτε οριζόντια ανάπτυξη QPS).
• Διαθεσιμότητα (ταχεία αποτυχία, κανένα σημείο αποτυχίας).
• Εντοπισμός δεδομένων (πολυπεριφέρεια, χαμηλή καθυστέρηση).
• απομόνωση θορυβωδών γειτόνων (θερμοί ενοικιαστές/θερμά κλειδιά).

2) Βασικοί όροι και υποδείγματα συνέπειας

Πρωταρχικό/Leader ↔ Replica/Follower: γράψτε στον αρχηγό, διαβάστε τα αντίγραφα.
Συγχρονισμένη αντιγραφή: επιβεβαίωση συναλλαγής μετά την εγγραφή σε N κόμβους (χαμηλή RPO, υψηλότερη καθυστέρηση).
Ασύγχρονη: ο επικεφαλής δεσμεύεται και στέλνει ημερολόγιο αργότερα (RPO> 0, χαμηλή καθυστέρηση).
Απαρτία (Raft/Paxos): γράφοντας στους περισσότερους κόμβους; ένα ημερολόγιο, αυτόματος οδηγός.
Ανάγνωση μετά την εγγραφή: εγγυημένη ανάγνωση των εγγραφών του (βλέπε § 5).

Διαβάζουμε την ΚΓΠ στις πωλήσεις όπως αυτή: σε περίπτωση προβλημάτων δικτύου, επιλέγετε συνέπεια (CP) ή διαθεσιμότητα (AP) για κρίσιμες λειτουργίες, συχνά συνδυάζοντας επίπεδα σε διαφορετικές διαδρομές.

3) Αντιγραφή: Επιλογές και πρακτικές

3. 1 Φυσική και λογική

Φυσικό (WAL/redo/binlog): πλησιέστερο στο λογάριθμο του συγκροτήματος, απλό και γρήγορο· περιορίζεται σε ομοιογενή τοπολογία/έκδοση.
Λογικό: ροή DML/DDL σε επίπεδο γραμμής/πίνακα. επιτρέπει μερικά αντίγραφα, διακλαδικές μεταναστεύσεις, CDC για DWH/streaming.

3. 2 Σύσταση και διαχείριση

Παρακολούθηση της υστέρησης (χρόνος/ψηφιολέξεις/LSN).
Περιορισμός της ανάδρασης σε θερμή αναμονή και των μακροχρόνιων αιτημάτων για αντίγραφα (ώστε να μην παρεμποδίζεται το κενό/καθαρισμός).
Για το MySQL - GTID και τον ενορχηστρωτή. PostgreSQL - χρονοθυρίδες Patroni/αναπαραγωγή, .

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 Τοπολογίες

(leader replica) + καταρράκτες (το αντίγραφο συγχωνεύεται περαιτέρω).
Πολυ-πρωτογενής (ενεργός) - αποφυγή στο OLTP χωρίς αυστηρή διαχείριση συγκρούσεων.
Σύμπλεγμα απαρτίας (Raft) - Πρόσθετα CockroachDB/Yugabyte/PG-Raft.

4) Διαβάστε/γράψτε split και routing

Πάντα να γράφεις ως ηγέτης. Διαβάστε από τις ατάκες, αλλά σκεφτείτε την καθυστέρηση.

1. Session stickiness: Μετά από μια επιτυχημένη ηχογράφηση, ο πελάτης διαβάζει από τον ηγέτη κατά τη διάρκεια του 'Δ T'.

2. Πύλη LSN/GTID: ο πελάτης λέει «Δεν θέλω να μεγαλώσω LSN = X», ο δρομολογητής στέλνει στο αντίγραφο, του οποίου LSN ≥ X.

3. Stale-ok: ορισμένα ερωτήματα επιτρέπουν μπαγιάτικα δεδομένα (καταλόγους/ταινίες).

Εργαλεία: PgBouncer/Pgpool-II (Postgres), ProxySQL/MaxScale (MySQL), Vitess (shard routing).

Παράδειγμα πύλης LSN (ιδέα): αποθήκευση 'pg _ current _ wal _ lsn ()' σε κεφαλίδα/cookie HTTP και απαίτηση του router να αντιγράψει με 'pg _ last _ wal _ replay _ lsn () ≥ LSN'.

5) Στρατηγικές επιμερισμού

5. Επιλογή κλειδιού

• Hash by 'tenant _ id '/' user _ id' - ομοιόμορφα, αλλά στερεί σαρώσεις εύρους.
• Εύρος χρόνου/ταυτότητας - μεγάλη για χρονοσειρές/αρχείο, αλλά κίνδυνος θερμού θραύσματος.
• Συνεκτικό hashing - καθιστά εύκολη την προσθήκη/αφαίρεση θραυσμάτων.
• Κατάλογος/πίνακας αναζήτησης - ευέλικτος (οποιοσδήποτε αλγόριθμος), αλλά άλλος πίνακας/κρύπτη.

5. 2 Μοτίβα

Κοινόχρηστο: κάθε θραύσμα είναι ξεχωριστή βάση δεδομένων/δέσμη, η εφαρμογή γνωρίζει δρομολόγηση.
Middleware-sharding: Vitess (MySQL), Citus (Postgres), Proxy-level κρύβει τοπολογία.
Ομοσπονδία: διαχωρισμός των πεδίων δεδομένων ανά υπηρεσία (κατάλογος, πληρωμές, auth).

5. 3 Σύνθετα κλειδιά

Χρησιμοποιήστε τον βασικό χώρο: '{ενοικιαστής}: {οντότητα}: {id}' και αποθηκεύστε τον στην εφαρμογή και την κρύπτη. Postgres - χωρισμός χασίς + τμήμα LIST/RANGE.

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-bit (χρόνος + περιοχή + θραύσμα + seq) ή ULID/KSUID (μονοτονία και κατανομή).
Postgres - ακολουθία ανά θραύσμα· για το MySQL - auto_increment_increment/offset (διαφορετικές αντισταθμίσεις για τους ηγέτες κομματιών).

7) Επιγραμμική υπέρμετρη κατανομή και μετανάστευση

Βασικές αρχές: διπλή γραφή, ταυτότητα, προσωρινή διπλή διαδρομή.

1. Προσθήκη νέου θραύσματος/συμπλέγματος.

2. Ενεργοποίηση διπλής ανάγνωσης (έλεγχος συνέπειας).

3. Συμπεριλάβετε διπλή γραφή (και στα δύο θραύσματα), διαφορές εγγραφής.

4. Backfill ιστορικά δεδομένα (παρτίδες, λογική/αντιγραφή CDC).

5. Μετάβαση της «πηγής της αλήθειας» σε ένα νέο θραύσμα. αφήστε τον συγχρονισμό «ουρά».

6. Απενεργοποιήστε το παλιό.

Εργαλεία: Vitess Resharding, Citus move θραύσματα, pg_logical/pgoutput, Debezium (CDC), gh-ost/pt-online-schema-change (DDL χωρίς κλειδαριές).

8) Πολυπεριφερειακή και γεωγραφική κατανομή

Leader-follower ανά περιοχή: τοπικά διαβάζει, γράφει - μέσω του παγκόσμιου ηγέτη (απλό μοντέλο, αλλά διαπεριφερειακό RTT).
Multi-leader: καταγραφή και στις δύο περιοχές - χρειάζεστε σύρραξη (χρονοσφραγίδα/έκδοση/CRDT).
Αληθινά κατανεμημένα SQL (Raft): CockroachDB/Yugabyte - τα δεδομένα είναι «κολλημένα» στην περιοχή, τα ερωτήματα πηγαίνουν στην τοπική απαρτία.

• Χρήματα/παραγγελίες - CP (απαρτία/επικεφαλής), κατάλογοι/ταινίες - AP (μνήμη, τελικά).
• Πάντα σχεδιάζετε να γράφετε ξιφασκία (μοναδικά κλειδιά/εκδόσεις) με πιθανό διαχωρισμό εγκεφάλου.

9) Συνοχή στην πράξη

Διαβάστε-σας-γράφει: ο ηγέτης ή σύνθημα που «έπιασε» με LSN/GTID.
Η Monotonic γράφει: «Όχι παλαιότερη» από την τελευταία ανάγνωση του LSN.
Έλεγχος εγγραφής συγκρούσεων: 'SELECT... ΓΙΑ ΕΝΗΜΕΡΩΣΗ ', εκδόσεις (' xmin '/' rowversion '), UPSERT με έλεγχο έκδοσης.
Idempotence: idempotence keys on payments/events.

10) Παρατηρησιμότητα, SLO και προειδοποιήσεις

Καθυστέρηση αντιγραφής: χρόνος (δευτερόλεπτα), απόσταση LSN (ψηφιολέξεις), seconds_behind_master (MySQL).
Αναγκαστικές ανατροπές/συγκρούσεις, σφάλματα αντιγραφής.
p95/p99 latency по route (read leader vs replica, write).
Διακίνηση: TPS/κλειδαριές/πίνακες με σειρά.
Bloat/VACUUM (PG), λόγος hit του ρυθμιστικού διαλύματος InnoDB (MySQL).
Dashboards: φορτίο ανά θραύσμα, θραύσματα «hot», κατανομή κλειδιών.

11) Αντίγραφα ασφαλείας, PITR και DR

Πλήρες εφεδρικό + WAL/binlog για PITR (point-in-time recovery).
Φυλάσσετε σε άλλη περιοχή/νέφος, αποκαθιστήστε τις εξετάσεις τακτικά.
Για θραύσματα, μια συνεπής «φέτα» (συντονισμός χρόνου/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 ανά πληρεξούσιο.
Ρόλοι/επιχορηγήσεις βάσει της αρχής των ελάχιστων δικαιωμάτων· μεμονωμένοι χρήστες ανά θραύσμα/ρόλο.
Έλεγχος DDL/DCL, περιορισμοί στα «βαριά» αιτήματα για αντίγραφα.
Κρυπτογράφηση σε ηρεμία (KMS) και σε διαμετακόμιση (TLS).
Κουμπί πανικού: Global 'READ ONLY' για τη διάρκεια του συμβάντος/έρευνας.

13) Εργαλεία και τούβλα

PostgreSQL: Patroni (HA), PgBouncer (κοινοπραξία/RO-routing), repmgr, pgBackRest/Barman (бэкап), Citus (шардинг), pglogical/Logical Replication, pgbadger/pg_stat_statements.
MySQL: Ενορχηστρωτής (τοπολογία/αυτόματη βλάβη), ProxySQL/MaxScale (δρομολόγηση), Percona Xtrabackup (backup), ομάδα αντιγραφής/σύμπλεγμα InnoDB, Vitess (sharding/resharding).
Κατανεμημένο SQL: CockroachDB, YugabytteDB (απαρτία, ενσωματωμένο sharding/geolocation).
CDC: Debezium + Kafka/Pulsar για εκδηλώσεις/ETL.

14) Αντι-μοτίβα

Μονό-πρωτεύον χωρίς αυτόματη βλάβη και χωρίς δοκιμές DR.
«Magic» read-split εκτός από σφάλματα υστέρησης/ύποπτα σφάλματα.
Συγκράτηση «για λόγους συγκράτησης»: πρόωρη επιπλοκή αντί για κατακόρυφη κλίμακα/δείκτες/μνήμη.
Θερμή περιοχή (χρονοδιάγραμμα) χωρίς κάδο χρόνου/αλάτι χασίς → λιώνει ένα θραύσμα.
Η παγκόσμια συναλλαγή 2PC πάνω από δεκάδες θραύσματα στο OLTP - ψηλά p99 ουρές και συχνές κλειδαριές.
Έλλειψη διπλής γραφής/διπλής ανάγνωσης κατά τη διάρκεια των μεταναστεύσεων - απώλεια/εκτός συγχρονισμού.
DDL χωρίς επιγραμμικά εργαλεία και χωρίς σημαίες συμβατότητας.

15) Κατάλογος ελέγχου εφαρμογής (0-60 ημέρες)

0- 15 ηµέρες

Ορισμός DB SLO, RPO/RTO.
Ενεργοποίηση αντιγραφής, παρακολούθησης καθυστέρησης, βασικών αντιγράφων ασφαλείας + PITR.
Εισάγετε τον δρομολογητή (PgBouncer/ProxySQL) και την πολιτική ανάγνωσης μετά την εγγραφή.

16- 30 ηµέρες

Επιλέξτε μια στρατηγική κοπής, περιγράψτε τα κλειδιά και τα σχήματα.
Προετοιμασία εργαλείων υπερφόρτισης (Vitess/Citus/CDC).
Κατάλογος υπηρεσιών/πινάκων με την ένδειξη "read-bale-ok" έναντι "stric .

31-60 ημέρες

Εκτέλεση πιλοτικού σκελετού, διπλής ανάγνωσης και οπισθοπλήρωσης.
Ημέρα παιχνιδιού: αποτυχία ηγέτη, ανάκαμψη από PITR, αλλαγή περιοχής.
Αυτόματη υποβολή εκθέσεων θερμού θραύσματος και ανομοιογένειας.

16) Μετρήσεις διάρκειας

Replica lag p95 <στόχος (π.χ. 500 ms) για κριτική ανάγνωση.
Επιτυχείς δοκιμές DR ≥ 1/τέταρτο (αποκατάσταση ≤ RTO, απώλεια ≤ RPO).
Κατανομή φορτίου ανά θραύσματα: ανισορροπία <20% ανά QPS/αποθήκευση.
Ποσοστό αιτήσεων με αυστηρή συνοχή που δρομολογήθηκαν σωστά = 100%.
Μηδενική απώλεια δεδομένων σε περιστατικά που απαιτούν εγγυήσεις CP (χρήμα/παραγγελίες).
Online DDL/μετάβαση χωρίς downtime, με σημαίες συμβατότητας.

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) Συμπέρασμα

Το ψαλίδι και η αναπαραγωγή δεν είναι μόνο μια τεχνική, αλλά και διαδικασίες: διαδρομή με συνοχή, μεταναστευτική πειθαρχία (διπλή γραφή/ανάγνωση, backfill), τακτικές δοκιμές DR, και lag/hot shard observability. Ξεκινήστε με ένα απλό + read-after-write leader→replica, και στη συνέχεια προσθέστε sharding όπου το προφίλ φορτίου το απαιτεί πραγματικά. Χρήση έτοιμων πλατφορμών (Vitess/Citus/Distributed SQL) και διατήρηση δεδομένων κρίσιμων για τις επιχειρήσεις σε λειτουργία CP - με αυτόν τον τρόπο η βάση θα πάψει να αποτελεί εμπόδιο και να καταστεί προβλέψιμο, ελαστικό θεμέλιο της πλατφόρμας.