Charding e replica dei database

Charding e replica dei database

1) Perché è necessario

• Larghezza di banda (altezza orizzontale write QPS).
• Disponibilità (failover veloce, nessun unico punto di guasto).
• Localizzazione dei dati (regione multi, bassa latitanza).
• Isolamento dei vicini rumorosi (hot tenants/hot keys).

2) Termini di base e modelli di coerenza

Primary/Leader di Replica/Follower: scrittura sul leader, lettura sulle repliche.
Replica sincrona: conferma transazione dopo scrittura su nodi N (RPO basso, latenza superiore).
Asincrona: il leader fissa il commit e invia il logo in seguito (RPO> 0, bassa latitanza).
Quorum (Raft/Paxos) - Scrittura per la maggior parte dei nodi; Un solo cronista, un leader automatico.
Read-after-write - Lettura garantita dei propri record (vedere l'articolo 5).

Quando si verificano problemi di rete, il CAP è in grado di scegliere la coerenza o la disponibilità per le operazioni critiche, spesso combinando i livelli su percorsi diversi.

3) Replica: opzioni e pratiche

3. 1 Fisica e logica

Fisico (WAL/redo/binlog) - Più vicino al registro a blocchi, semplice e veloce; limitato alla topologia/versione omogenea.
Logico: flusso DML/DDL a livello di righe/tabelle; consente repliche parziali, migrazioni tra versioni, CDC per DWH/streaming.

3. 2 Configurazione e gestione

Controlla lag (tempo/byte/LSN).
Limitare gli hot-standby feedback e le lunghe richieste di repliche (per non interrompere VACUUM/clining).
Per MySQL - GTID e 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 Topologie

1→N (leader della replica →) + cascata (replica più avanti).
Multi-primary (active-active) - Evitare in OLTP senza una gestione rigorosa del conflitto.
Quorum-cluster (Raft) - CockroachDB/Yugabyte/PG-Raft-plug-in.

4) Read/Write Split e routing

Scrivete sempre come leader; leggete le repliche, ma tenete in considerazione le lag.

1. Sessione stick© - Dopo aver registrato con successo, il cliente legge con il leader durante l'outlook dì T ".

2. Gate LSN/GTID: il client dice: «Non voglio più vecchio LSN = X», il router invia una replica con LSN X.

3. State-ok: una parte delle query consente dati obsoleti (directory/nastri).

Utensili: PgBouncer/Pgpool-II (Postgres), ProxySQL/MaxScale (MySQL), Vitess (instradamento dei sardi).

Esempio di gate LSN: salva 'pg _ current _ wal _ lsn ()' in HTTP-heder/cooking e richiedi al router una replica con'pg _ last _ wal _ replay _ lsn '.

5) Strategie di Charding

5. 1 Selezione chiave

• Hash in'tenant _ id '/' user _ id 'è uniforme, ma priva di range-scan.
• Range tempo/ID è ottimo per time-series/archivio, ma il rischio è hot-shard.
• Consistent hasing - Semplifica l'aggiunta/rimozione di chard.
• Directory/lookup è una tabella flessibile (qualsiasi algoritmo), ma un'altra tabella/cache.

5. 2 Pattern

Shared-nothing: ogni shard è un database/cluster separato, l'applicazione conosce il routing.
Middleware-sharding: Vitess (MySQL), Citus (Postgres), Livello Proxy nasconde la topologia.
Federazione: separazione dei domini dei servizi (catalog, payments, auth).

5. 3 Chiavi composite

Utilizzare lo spazio chiave: '{tenant}: {entity}: {id}' e memorizzarlo nell'applicazione e nella cache. Для 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) Generazione di identificatori

Evitate gli impianti di sharding «hot» monouso.
Utilizzare Snowflake-simili a 64 bit ID (time + region + shard + seq) o ULID/KSUID (monotonia e distribuzione).
Для Postgres — sequence per shard; per il MySQL-auto _ increment _ increment/offset (diversi offset sui leader dei sardi).

7) Migrazione e migrazione online

I principi chiave sono il doppio record (dual-write), l'idimpotenza, il doppio instradamento temporaneo.

1. Aggiungi un nuovo shard/cluster.

2. Attivare il controllo di consistenza dual-read.

3. Attivare il dual-write (in entrambi gli shard) e fissare le discrepanze.

4. Eseguire il backfill dei dati storici (batch, replica logica/CDC).

5. Spostate la fonte della verità in un nuovo shard; lasciate la sincronizzazione di coda.

6. Spegnete il vecchio.

Strumenti: Vitess Resharding, Citus move shards, pg _ logical/pgoutput, Debezium (CDC), gh-ost/pt-online-schema-change (DDL senza blocchi).

8) Regione multi e distribuzione geografica

Leader-follower per region: lettura locale, scrittura tramite un leader globale (modello semplice ma cross-region RTT).
Multi-leader - Scrittura in entrambe le regioni - È necessario un conflitto-merjing (timestamp/versione/CRDT).
True distributed SQL (Raft) - CockroachDB/Yugabyte - I dati sono «incollati» alla regione e le richieste vanno al quorum locale.

• Denaro/ordini - CAP (quorum/leader), cataloghi/nastri - AP (cache, avvenual).
• Pianifica sempre il write fencing (chiavi uniche/versioning) quando possibile split-brain.

9) Coerenza nella pratica

Read-your-writes: il leader o la replica che ha raggiunto LSN/GTID.
Monotonic reads: «non più vecchio» dell'ultimo LSN letto.
Write-conflict control: `SELECT... FOR UPDATE, versione ('xmin '/' rowversion'), versione UPSERT con convalida versione.
Idampotenza: chiavi di idempotenza su pagamenti/eventi.

10) Osservazione, SLO e alert

Repliche: tempo (secondi), LSN distanza (byties), seconds _ behind _ master (MySQL).
Ripristini/conflitti forzati, errori di replica.
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: carico per-shard, hot chard, distribuzione delle chiavi.

11) Bacapi, PITR e DR

Backup completo + WAL/binlog per PITR (point-in-time recovery).
Conservare in un'altra regione/cloud, eseguire regolarmente test di restore.
Per i sardi, un taglio coerente (coordinare il tempo/LSN) o un'idampotenza applicativa durante il ripristino.
RPO/RTO sono prescritti e testati su game-days.

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

12) Sicurezza e accesso

Segmentazione VPC/ACL per il proxy.
Ruoli/borse di studio in base ai diritti minimi; Utenti singoli per shard/ruolo.
Controllo DDL/DCL, limiti per le richieste di replica pesanti.
Crittografia at rest (KMS) e in transito (TLS).
Global READ ONLY durante l'incidente/indagine.

13) Strumenti e mattoni

PostgreSQL: Patroni (HA), PgBouncer (pooling/RO-routing), repmgr, pgBackRest/Barman (бэкап), Citus (шардинг), pglogical/Logical Replication, pgbadger/pg_stat_statements.
MySQL: Orchestrator (topologia/auto-failover), ProxySQL/MaxScale (routing), Percona XtraBackup, Group Replication/InnoDB Cluster, Vitess (charding/resharding).
Distributed SQL: CockroachDB, YugabyteDB (quorum, sharding incorporato/geolocalizzazione).
CDC: Debezium + Kafka/Pulsar per eventi/ETL.

14) Anti-pattern

Single-primary senza auto-failover e senza test DR.
Il «magico» read-split senza considerare il suo lag, è un errore fantasma o un errore sospetto.
Sharding per lo sharding, complicazione prematura al posto dello skale verticale/indice/cache.
L'intervallo caldo (time-range) senza time-bucket/hash-salt si scioglie.
Transazione globale 2PC sopra decine di chard in OLTP: code p99 elevate e blocchi frequenti.
L'assenza di dual-write/dual-read durante le migrazioni è una perdita/rassincrone.
DDL in vendita senza strumenti online e senza flag fit compatibilità.

15) Assegno foglio di implementazione (0-60 giorni)

0-15 giorni

Identificare SLO database, RPO/RTO.
Abilita la replica, il monitoraggio lag, i backup di base + PIT.
Immettere il router (PgBouncer/ProxySQL) e il criterio read-after-write.

16-30 giorni

Scegliere una strategia di sharding, descrivere le chiavi e gli schemi.
Prepara gli strumenti di spostamento (Vitess/Citus/CDC).
Catalogo di servizi/tabelle con l'etichetta «read-stale-ok» vs «strict».

31-60 giorni

Avvia pilot-shard, dual-read e backfill.
Game-day: failover leader, recupero da PITR, cambio regione.
Automatizzare i rapporti su chiavi hot shard e disuguaglianze.

16) Metriche di maturità

Replica lag p95 <target (ad esempio 500 ms) per le letture critiche.
Test DR di successo 1/trimestre (restore) RTO, perdita di RPO.

Lo squilibrio <20% per QPS/Storage

Percentuale di richieste con strict-consistency correttamente routata = 100%.
Zero-data-loss in incidenti che richiedono garanzie COP (denaro/ordini).
DDL/migrazioni online senza interruzioni, con bandiere di compatibilità.

17) Esempi di ricette

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) Conclusione

Lo sharding e la replica non sono solo tecniche, ma anche processi: routing in base alla coerenza, disciplina delle migrazioni (dual-write/read, backfill), test DR regolari e osservabilità dei chard hot. Iniziate con un semplice leader→replica + read-after-write, quindi aggiungete lo sharding dove il profilo di carico lo richiede davvero. Utilizzare le piattaforme finite (Vitess/Citus/Distributed SQL) e mantenere i dati critici aziendali in modalità CC, in modo che la base non sia più una gola di bottiglia e diventi una base prevedibile ed elastica della piattaforma.