A replicação transmite as mudanças de uma fonte (master) para uma ou mais réplicas. A fonte registra toda mudança confirmada em seu binary log (binlog); a thread de I/O de cada réplica copia esse log e uma thread de SQL/applier o reaplica, de modo que as réplicas convergem para os mesmos dados.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (registra as imagens reais das linhas, padrão seguro), STATEMENT ou MIXED.Aponte as escritas para a fonte e distribua os SELECTs pelas réplicas. Aplicações com muitas leituras (a maioria das apps web) escalam leituras quase linearmente adicionando réplicas, enquanto a única fonte ainda cuida de todas as escritas.
-- On a replica, watch how far behind it is:
SHOW REPLICA STATUS\G
-- Seconds_Behind_Source: 2 <- replication lag
-- Replica_IO_Running: Yes
-- Replica_SQL_Running: Yes
Como as réplicas assíncronas ficam atrás da fonte, um usuário que escreve e imediatamente lê de uma réplica pode não ver a própria mudança (violação de "read-your-writes"). Roteie leituras sensíveis à latência ou recém-gravadas para a fonte, ou use semi-sync.
A replicação é o primeiro passo padrão para escalar leituras e ganhar um standby quente para failover/backups. Sua limitação definidora — o lag, e o único gargalo de escrita — molda projetos reais: explica por que às vezes você lê dados desatualizados e por que o scaling de escrita eventualmente precisa de sharding, não apenas mais réplicas.
Uma biblioteca de perguntas de entrevista de TI com respostas detalhadas — de Júnior a Sênior.
Doar