La replicación transmite los cambios desde una fuente (master) a una o más réplicas. La fuente registra cada cambio confirmado en su binary log (binlog); el hilo de E/S de cada réplica copia ese log y un hilo SQL/aplicador lo reproduce, de modo que las réplicas convergen a los mismos datos.
writes
app ---------> --- binlog ---> <-- reads
| <-- reads
+---------- binlog ---> <-- reads
ROW (registra las imágenes reales de las filas, predeterminado seguro), STATEMENT, o MIXED.Dirige las escrituras a la fuente y reparte los SELECT entre las réplicas. Las apps con muchas lecturas (la mayoría de las apps web) escalan las lecturas casi linealmente añadiendo réplicas, mientras la única fuente sigue gestionando todas las escrituras.
-- 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 las réplicas asíncronas van por detrás de la fuente, un usuario que escribe y luego lee de inmediato de una réplica puede no ver su propio cambio (violación de "read-your-writes"). Enruta las lecturas sensibles a la latencia o recién escritas a la fuente, o usa semi-síncrona.
La replicación es el primer paso estándar para escalar lecturas y para obtener un standby caliente para failover/copias de seguridad. Su limitación definitoria — el retraso, y el único cuello de botella de escritura — moldea los diseños reales: explica por qué a veces lees datos obsoletos y por qué escalar las escrituras acaba requiriendo sharding, no solo más réplicas.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar