Charding e replicação de banco de dados

Charding e replicação de banco de dados

1) Por que é necessário

• Largura de banda (crescimento horizontal write QPS).
• Disponibilidade (failover rápido, sem ponto de falha único).
• Localização de dados (região multi, baixa latência).
• Isolamento de vizinhos ruidosos (hot tenants/hot keys).

2) Termos básicos e modelos de coerência

Primary/Líder ↔ Replica/Follower: gravação no líder, leitura nas réplicas.
Replicação sincronizada: confirmação de transação após gravação em nódulos N (RPO baixo, latência superior).
Asincrona: o líder capta o comite e envia o logo mais tarde (RPO> 0, baixa latência).
Quórum (Raft/Paxos): gravação para a maioria dos nós; Um loga, um líder automático.
Read-after-write: leitura garantida de suas gravações (consulte nos 5).

O CAP em venda lê-se assim: em caso de problemas de rede, você escolhe a coerência ou a disponibilidade (AP) para operações críticas, muitas vezes combinando níveis em diferentes caminhos.

3) Replicação: opções e práticas

3. 1 Física e Lógica

Físico (WAL/redo/binlog): mais próximo do diário de blocos, simples e rápido; restrito à topologia homogênea/versão.
Lógico: fluxo de DML/DDL ao nível de linhas/tabelas; permite réplicas parciais, migração entre versões, CDC para DWH/streaming.

3. 2 Configuração e gerenciamento

Controle a lag (tempo/bytes/LSN).
Limite o hot-standby feedback e as longas solicitações em réplicas (para não desativar VACUUM/clining).
Para MySQL - GTID e Orquestrador; для 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 Topologias

1→N (líder → réplica) + cascata (a réplica é fundida mais adiante).
Multi-primary (ativo-ativo) - evitar no OLTP sem gerenciamento de conflito rigoroso.
O Korum-cluster (Raft) é um complemento CocroachDB/Yugabyte/PG-Raft.

4) Read/Write Split e rotação

Escreva sempre como líder; leia com as frases, mas leve em conta a lag.

1. Sessão stickiness: Depois de uma gravação bem sucedida, o cliente lê com o líder durante o processo de ' T'.

2. LSN/GTID-gate: O cliente diz «não quero mais LSN = X», o roteador envia para uma réplica cujo LSN ≥ X.

3. Stale-ok: parte das solicitações permite dados obsoletos (diretórios/fitas).

Ferramentas: PgBouncer/Pgpool-II (Postgres), ProxySQL/MaxScale (MySQL), Vitess (rotação de chardes).

Exemplo de LSN-gate (ideia): mantenha 'pg _ current _ wal _ lsn ()' em HTTP-heder/cook e exija uma réplica do roteador com 'pg _ last _ wal _ replay _ lsn () ≥ LSN'.

5) Estratégias de charding

5. 1 Escolha da chave

• Hash por 'tenant _ id '/' user _ id' é uniforme, mas priva as raias de range.
• Range em tempo/ID é excelente para time-series/arquivo, mas risco hot-shard.
• Consent hasing - facilita a adição/remoção de chardes.
• Diretoria/lookup-tabela - flexível (qualquer algoritmo), mas outra tabela/dinheiro.

5. 2 Patternes

Shared-nothing: Cada shard é um BB/cluster separado, o aplicativo conhece o roteiro.
Middleware-charding: Vitess (MySQL), Citus (Postgres), Nível Proxy esconde topologia.
Federação: divisão de domínios de dados de serviços (catalog, payments, auth).

5. 3 Chaves compostas

Use o espaço de chave: 'Se você quiser que você use o aplicativo e o console. Для 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) Geração de identificadores

Evite os carros monótonos quentes no charding.
Use o Snowflake de 64 bits de ID (time + region + shard + seq) ou o ULID/KSUID (monotonia e distribuição).
Для Postgres — sequence per shard; para MySQL - auto _ increment _ increment/offset (diferentes offsets na liderança dos chards).

7) Translação online e migração

Princípios-chave: dupla gravação (dual-write), idempotidade, duplicação temporária.

1. Adicione um novo shard/cluster.

2. Ative o dual-read (teste de consistência).

3. Ative o dual-write (em ambos os shards) e verifique as diferenças.

4. Execute o backfill de dados históricos (batchi, replicação lógica/CDC).

5. Alterna «origem da verdade» para um novo shard; deixe a sincronização de cauda.

6. Desliguem o velho.

Ferramentas: Vitess Resharding, Citus move shards, pg _ logical/pgoutput, Debezium (CDC), gh-ost/pt-online-schema-mudança (DDL sem bloqueios).

8) Região multi e distribuição geográfica

Líder-follower per region: leitura local, gravação - através de um líder global (modelo simples, mas cross-region RPT).
Multi-líder: gravação em ambas as regiões - precisa de conflito-merjing (timestamp/versão/CRDT).
True distribuído SQL (Raft): CockroachDB/Yugabyte - Os dados estão «colados» na região, e as solicitações vão para quórum local.

• Dinheiro/encomendas - COP (quórum/líder), diretórios/fitas - AP (dinheiro, eventual).
• Planeje sempre write fencing (chaves únicas/versioning) para um possível split-brain.

9) Coerência na prática

Read-your-writes: Líder ou réplica que «alcançou» LSN/GTID.
Monotonic reads: «no máximo» LSN mais recente lido.
Write-conflict control: `SELECT... FOR UPDATE ', versões (' xmin '/' rowversion '), UPSERT com validação de versão.
Idempotidade: chaves de idempotação em pagamentos/eventos.

10) Observabilidade, SLO e alertas

Réplicas: Tempo (segundos), LSN distância (bytes), segunds _ behind _ master (MySQL).
Reversões/conflitos forçados, erros de replicação.
p95/p99 latency по route (read leader vs replica, write).
Throughput: TPS/locks/row-contended tables.
Bloat/VACUUM (PG), InnoDB buffer pool hit ratio (MySQL).
Carga per-shard, chardes quentes, distribuição de chaves.

11) Bacapes, PITR e DR

Backup completo + WAL/binlog para PITR (point-in-time recovery).
Armazenem noutra região/nuvem, façam testes de restore regularmente.
Para os chardes, «corte» alinhado (coordenação do tempo/LSN) ou idempotação aplicável na recuperação.
RPO/RTO são especificados e testados em game-days.

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

12) Segurança e acesso

Segmentação VPC/LCA mTLS no proxy.
Papéis/bolsas de direitos mínimos; usuários individuais para shard/rol.
Auditoria do DDL/DCL, limites para solicitações «pesadas» em réplicas.
Criptografia at rest (KMS) e em trânsito (TLS).
Botão de pânico: Global 'READ ONLY' durante o incidente/investigação.

13) Ferramentas e tijolos

PostgreSQL: Patroni (HA), PgBouncer (pooling/RO-routing), repmgr, pgBackRest/Barman (бэкап), Citus (шардинг), pglogical/Logical Replication, pgbadger/pg_stat_statements.
MySQL: Orquestrador (topologia/auto-failover), ProxySQL/MaxScale (routing), Percona XtraBackup (bacap), Group Replication/InnoDB Cluster, Vitess (charding/resharding).
Distribuído SQL: CockroachDB, YugabyteDB (quórum, charding embutido/geolocalização).
CDC: Debezium + Kafka/Pulsar para eventos/ETL.

14) Anti-pattern

Single-primary sem auto-failover e sem testes DR..
«Mágico» read-split sem contar com a lag → erros fantasmas/bags suspeitos.
Charding por charding, complicação prematura em vez de skale/índice/cachê vertical.
Uma faixa quente (time-range) sem time-bucket/hash-salt → um shard derrete.
Transação global de 2PC acima de dezenas de chardes no OLTP - colas de p99 altas e bloqueios frequentes.
Falta de dual-write/dual-read nas migrações → perda/desabastecimento.
DDL em venda sem ferramentas on-line e sem bandeiras de compatibilidade fiche.

15) Folha de cheque de implementação (0-60 dias)

0-15 dias

Definir SLO BD, RPO/RTO.
Incluir replicação, monitoramento de lag, bacapes básicos + PITR.
Digite o roteador (PgBouncer/ProxySQL) e a política read-after-write.

16-30 dias

Escolha uma estratégia de charding, descreva as chaves e os esquemas.
Preparar ferramentas de reposição (Vitess/Citus/CDC).
Catálogo de serviços/tabelas com «read-stale-ok» vs «strict».

31-60 dias

Iniciar pilot shard, dual-read e backfill.
Game-day: líder failover, restauração de PITR, mudança de região.
Automatizar relatórios de chaves shard quentes e desigual.

16) Métricas de maturidade

Replica lag p95 <alvo (por exemplo, 500 ms) para leitura crítica.
Testes DR. bem sucedidos ≥ 1/trimestre (restore ≤ RTO, perda de ≤ RPO).
Alinhamento de carga por chard: desequilíbrio <20% em QPS/armazenamento.
A proporção de solicitações com strict-consistency, corretamente roteirizada, = 100%.
Zero-data-loss em incidentes que exigem garantias CP (dinheiro/encomendas).
DDL/migração online sem interrupções, com bandeiras de compatibilidade.

17) Exemplos de receitas

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) Conclusão

Charding e replicação não são apenas técnicas, mas também processos: rotação com consistência, disciplina de migração (dual-write/read, backfill), testes DR regulares e observabilidade de lag/chard quente. Comece com um simples leader→replica + read-after-write, e depois adicione um charding onde o perfil de carga é realmente necessário. Use plataformas prontas (Vitess/Citus/Distribuído SQL) e mantenha os dados críticos de negócios em modo COP - de modo que a base deixe de ser um gargalo de garrafa e se torne uma base previsível e elástica da plataforma.