Charding y replicación de bases de datos

Charding y replicación de bases de datos

1) Por qué es necesario

• Ancho de banda (crecimiento horizontal de write QPS).
• Disponibilidad (failover rápido, sin un único punto de falla).
• Localización de datos (multi-región, baja latencia).
• Aislamiento de vecinos ruidosos (hot tenants/hot keys).

2) Términos básicos y modelos de coherencia

Primary/Leader ↔ Replica/Follower: escribir en líder, leer en réplicas.
Replicación sincrónica: confirmación de la transacción después de escribir en N nodos (RPO baja, latencia superior).
Asincrónico: el líder registra el commit y envía el registro más tarde (RPO> 0, baja latencia).
Quórum (Raft/Paxos): permite escribir en la mayoría de los nodos; un registro, un líder automático.
Leer después de escribir: Lectura garantizada de sus registros (ver § 5).

CAP en venta lo leemos así: en problemas de red, elige consistencia (CP) o disponibilidad (AP) para operaciones críticas, a menudo combinando niveles en diferentes rutas.

3) Replicación: opciones y prácticas

3. 1 Físico y lógico

Físico (WAL/redo/binlog): más cercano al registro de bloques, simple y rápido; limitado a la topología homogénea/versión.
Lógico: flujo DML/DDL a nivel de filas/tablas; permite réplicas parciales, migraciones entre versiones, CDC para DWH/streaming.

3. 2 Configuración y administración

Controle el lag (tiempo/bytes/LSN).
Limite el feedback hot-standby y las solicitudes de réplicas largas (para no costear VACUUM/limpieza).
Para MySQL - GTID y 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 Topologías

1→N (líder → réplica) + cascadas (réplica drena más).
Multi-primary (active-active): evite en OLTP sin una gestión de conflictos estricta.
El clúster Quorum (Raft) es un complemento CockroachDB/Yugabyte/PG-Raft.

4) Read/Write Split y enrutamiento

Escriba siempre al líder; Lea con réplicas, pero tenga en cuenta el lag.

1. Stickiness de sesión: después de una grabación exitosa, el cliente lee con el líder durante el 'Δ T'.

2. Puerta LSN/GTID: el cliente informa «quiero no envejecer LSN = X», el router envía a una réplica cuyo LSN ≥ X.

3. Stale-ok: parte de las consultas permiten datos obsoletos (directorios/cintas).

Herramientas: PgBouncer/Pgpool-II (Postgres), ProxySQL/MaxScale (MySQL), Vitess (enrutamiento Shard).

Ejemplo de gate LSN (idea): guarde 'pg _ current _ wal _ lsn ()' en un header/cookie HTTP y requiera una réplica del router con 'pg _ last _ wal _ replay _ lsn () ≥ LSN'.

5) Estrategias de charding

5. 1 Selección de clave

• Hash por 'tenant _ id '/' user _ id' - uniformemente, pero priva a los escáneres de rango.
• Range por tiempo/ID - Excelente para la serie de tiempo/archivo, pero el riesgo es hot-shard.
• Consistent hashing - Facilita la adición/eliminación de chardos.
• Directory/lookup-table es flexible (cualquier algoritmo), pero otra tabla/caché.

5. 2 Patrones

Shared-nothing: cada shard es un BD/clúster separado, la aplicación conoce el enrutamiento.
Middleware-charding: Vitess (MySQL), Citus (Postgres), Proxy-level oculta la topología.
Federación: dividir los dominios de datos por servicios (catalog, payments, auth).

5. 3 Llaves compuestas

Utilice el espacio clave: '{tenant}: {entity}: {id}' y almacene el mismo en la aplicación y en la caché. Для 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) Generación de identificadores

Evite las inyecciones de auto monótonas «calientes» en el charding.
Utilice un ID similar a Snowflake de 64 bits (time + region + shard + seq) o ULID/KSUID (monotonía y distribución).
Для Postgres — sequence per shard; para MySQL - auto_increment_increment/offset (diferentes offsets en los líderes de shards).

7) Transición y migración en línea

Principios clave: doble escritura (dual-write), idempotencia, doble enrutamiento temporal.

1. Agregue un nuevo shard/clúster.

2. Habilite la lectura dual (verificación de consistencia).

3. Incluye dual-write (en ambos shardos), captura las discrepancias.

4. Ejecute backfill de datos históricos (batch, replicación lógica/CDC).

5. Cambie la «fuente de la verdad» a una nueva shard; deje la sincronización de «cola».

6. Apague el viejo.

Herramientas: Vitess Resharding, Citus move shards, pg_logical/pgoutput, Debezium (CDC), gh-ost/pt-online-schema-change (DDL sin bloqueos).

8) Multi-región y distribución geográfica

Leader-follower per region: lecturas locales, escritura - a través de un líder global (modelo simple, pero RTT de región cruzada).
Multi-leader: grabación en ambas regiones - necesita conflicto-merjing (timestamp/versión/CRDT).
True distributed SQL (Raft): CockroachDB/Yugabyte - los datos están «pegados» a la región, las consultas van al quórum local.

• Dinero/pedidos - CP (quórum/leader), catálogos/cintas - AP (caché, eventual).
• Siempre planifique el fencing escrito (llaves únicas/versionar) con un posible split-brain.

9) Coherencia en la práctica

Read-your-writes: el líder o la réplica que «se puso al día» con LSN/GTID.
Monotonic reads: «no más antiguo» que el último LSN leído.
Write-conflict control: `SELECT... FOR UPDATE ', versiones (' xmin '/' rowversion '), UPSERT con revisión de versión.
Idempotencia: claves de idempotencia en pagos/eventos.

10) Observabilidad, SLO y alertas

Lag réplicas: tiempo (sec), distancia LSN (bytes), seconds_behind_master (MySQL).
Retrocesos/conflictos forzados, errores de replicación.
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: carga per-shard, bolardos «calientes», distribución de llaves.

11) Backups, PITR y DR

Backup completo + WAL/binlog para PITR (recuperación de puntos en tiempo).
Almacene en otra región/nube, haga pruebas de restauración regularmente.
Para los chardos, un «corte» consistente (coordinación de tiempo/LSN) o idempotencia aplicativa en la recuperación.
RPO/RTO están prescritos y probados en días de juego.

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

12) Seguridad y acceso

Segmentación por VPC/ACL, mTLS en un proxy.
Funciones/subvenciones en virtud del principio de los derechos mínimos; usuarios individuales en shard/rol.
Auditoría de DDL/DCL, límites para solicitudes de réplicas «pesadas».
Encriptación en nat (KMS) y en tránsito (TLS).
«Pánico-botón»: global 'READ ONLY' mientras dure el incidente/investigación.

13) Herramientas y ladrillos

PostgreSQL: Patroni (HA), PgBouncer (pooling/RO-routing), repmgr, pgBackRest/Barman (бэкап), Citus (шардинг), pglogical/Logical Replication, pgbadger/pg_stat_statements.
MySQL: Orchestrator (topologías/auto-failover), ProxySQL/MaxScale (enrutamiento), Percona XtraBackup (respaldo), Group Replication/InnoDB Cluster, Vitess (sharding/resharding).
SQL distribuido: CockroachDB, YugabyteDB (quórum, charding/geolocalización incorporada).
CDC: Debezium + Kafka/Pulsar para eventos/ETL.

14) Anti-patrones

Single-primary sin auto-failover y sin pruebas de DR.
«Magic» read-split, sin tener en cuenta el lag → errores fantasma/errores sospechosos.
Charding «por el bien del charding»: complicación prematura en lugar del skale vertical/índices/caché.
Rango caliente (time-range) sin time-bucket/hash-salt → un shard se derrite.
Transacción global 2PC encima de docenas de shards en OLTP: colas p99 altas y bloqueos frecuentes.
No hay dual-write/dual-read en las migraciones → pérdida/rassinchron.
DDL en venta sin herramientas en línea y sin banderas de compatibilidad.

15) Lista de verificación de implementación (0-60 días)

0-15 días

Definir SLO DB, RPO/RTO.
Habilite la replicación, el monitoreo de lag, los backups básicos + PITR.
Introduzca el router (PgBouncer/ProxySQL) y la política read-after-write.

16-30 días

Seleccione una estrategia de sharding, describa las claves y los esquemas.
Preparar herramientas de transición (Vitess/Citus/CDC).
Directorio de servicios/tablas marcado "read-stale-ok" vs "strict'.

31-60 días

Ejecutar pilot-shard, dual-read y backfill.
Día de juego: líder fallero, recuperación de PITR, cambio de región.
Automatice los informes de las llaves shard en caliente y la disparidad.

16) Métricas de madurez

Replica lag p95 <objetivo (por ejemplo, 500 ms) para lecturas críticas.
Pruebas DR exitosas ≥ 1/trimestre (restore ≤ RTO, pérdida ≤ RPO).
Distribución de carga por shard: desequilibrio <20% por QPS/almacenamiento.
Porcentaje de consultas con consistencia strict, correctamente enrutado, = 100%.
Cero-datos-perdidos en incidentes que requieren garantías CP (dinero/pedidos).
DDL en línea/migración sin downtime, con banderas de compatibilidad.

17) Ejemplos de recetas

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) Conclusión

El charding y la replicación no solo son técnicas, sino también procesos: enrutamiento con consistencia en mente, disciplina de migración (dual-write/read, backfill), pruebas de DR regulares y observabilidad de chardos de log/hot. Comience con un simple leader→replica + read-after-write, luego agregue el sharding donde el perfil de carga realmente lo requiera. Utilice plataformas listas para usar (Vitess/Citus/Distributed SQL) y mantenga los datos críticos del negocio en modo CP, por lo que la base dejará de ser un cuello de botella y se convertirá en la base predecible y elástica de la plataforma.