Replicación¶
La replicación es la base de casi todo lo que se espera de una base de datos seria: alta disponibilidad, escala de lectura, migración sin parada, distribución geográfica y recuperación en otra región. También es el mecanismo que se degrada más silenciosamente — una réplica parada hace semanas sigue respondiendo consultas, con datos viejos.
Esta página trata los mecanismos. Las topologías completas por motor están en MySQL, PostgreSQL y ClickHouse.
Elegir la topología es elegir un RPO y un costo por transacción — no una preferencia.
Física o lógica¶
| Replicación física | Replicación lógica | |
|---|---|---|
| Qué viaja | Bloques / registros del log de transacciones | Filas alteradas, a nivel de operación |
| Fidelidad | Copia byte a byte del primario | Selectiva: tablas y columnas elegidas |
| Versiones | Exige la misma versión mayor | Tolera versiones distintas |
| Destino | Solo lectura | Puede recibir escritura propia |
| Costo | Menor | Mayor, por fila aplicada |
| Uso típico | Alta disponibilidad, standby de failover | Migración, actualización de versión, extracción para BI |
Un clúster de producción suele usar ambas: física para las réplicas de failover, lógica para migrar, actualizar versión o alimentar a un consumidor externo.
Modos de confirmación¶
El modo define el RPO — cuántos datos es aceptable perder.
| Modo | Confirmación del COMMIT | RPO | Costo |
|---|---|---|---|
| Asíncrona | Inmediata; el primario no espera a la réplica | Segundos de datos en riesgo | Menor latencia de escritura |
| Semi-síncrona / quórum | Tras la confirmación de recepción de al menos una réplica | Cercano a cero | Algunos milisegundos por transacción |
| Síncrona estricta | Tras la aplicación en la réplica | Cero | Mayor; la réplica entra en el camino crítico |
| Entre regiones | Ídem, con réplica en la otra región | Cercano a cero, sobrevive a la pérdida de una región | La latencia del enlace metropolitano |
El arreglo más común: una réplica semi-síncrona para garantizar el dato y una réplica asíncrona para lectura e informes, sin poner el informe en el camino crítico de la escritura.
Una réplica no es una copia de seguridad
La replicación copia fielmente también el error. Un DROP TABLE en el primario llega a la réplica en milisegundos. Contra el error humano y la corrupción lógica, lo que protege es una copia con point-in-time recovery.
Topologías¶
- Primario con réplicas — el estándar. Una fuente de escritura, varias de lectura.
- Cascada — una réplica alimenta a otras. Alivia al primario cuando hay muchos consumidores, al costo de sumar lag en cada salto.
- Entre regiones — réplica en br-sp-1 y br-sp-2, interconectadas por enlaces Lan2Lan o túneles cifrados. Vea MySQL Multi-Región y PostgreSQL Multi-Región.
- Multi-escritura distribuida — sin primario único, con consenso por range. Es el modelo de CockroachDB, y resuelve la escritura local en varias regiones — problema que la replicación clásica no resuelve.
Direccionamiento de lectura¶
Tener réplicas no escala la lectura por sí solo: la aplicación tiene que usarlas. El direccionamiento va en la capa de proxy, no repartido por el código:
- ProxySQL (MySQL) y PgBouncer con endpoints separados (PostgreSQL) exponen
-rwy-ro. - Las consultas de informes y exportación van siempre a réplica.
- La lectura que exige el dato recién escrito (read-your-writes) permanece en el primario, o usa un mecanismo de espera por posición de replicación.
Lag: qué monitorear¶
El lag es la métrica de salud de la replicación, y necesita más de un ángulo:
| Métrica | Qué revela |
|---|---|
| Retraso en segundos | La visión del negocio: cuán viejo es el dato de la réplica |
| Distancia en bytes / posición del log | Si la réplica se está quedando atrás progresivamente |
| Estado de los procesos de replicación | Réplica parada por error — el peor caso, porque el retraso en segundos puede hasta parecer estable |
| Espacio del log retenido en el primario | El primario guarda log para réplicas atrasadas; una réplica trabada puede llenar el disco del primario |
Causas frecuentes de lag: escritura en lote demasiado grande en el primario, réplica con hardware inferior, aplicación de cambios en un solo hilo, transacción larga abierta en la réplica, o I/O saturado.
Una alerta de lag necesita dos umbrales
Uno para el retraso aceptable del negocio (por ejemplo, 30 segundos) y otro para un lag creciente durante varios minutos — porque una réplica que se aleja despacio llega al punto de necesitar reconstrucción.
Reconstrucción de réplica¶
Cuando la réplica queda atrás más allá del log retenido, o presenta divergencia, se reconstruye — no se "arregla":
- quitar la réplica del direccionamiento de lectura;
- recrearla a partir de una copia física o un snapshot reciente;
- retomar la replicación desde la posición registrada (GTID/LSN);
- esperar a que el lag llegue a cero;
- verificar consistencia con checksum de muestra;
- devolverla al direccionamiento de lectura.
En Kubernetes ese ciclo lo conduce el operador; en máquinas virtuales, un script versionado en el runbook.
Failover en una frase¶
Una réplica solo vale como protección si la promoción es confiable: detección con más de un observador, fencing del primario antiguo, promoción de la réplica más avanzada y redirección por el proxy. El detalle está en MySQL, PostgreSQL y en el plan de recuperación ante desastres.
Páginas Relacionadas¶
- Copias de Seguridad y Restauración — Lo que la replicación no protege
- Recuperación ante Desastres — Replicación entre regiones en el plan de DR
- Optimización de Rendimiento — Escalar lectura sin sobrecargar al primario
- Migración — La replicación lógica como herramienta de migración
- MySQL · PostgreSQL · ClickHouse · CockroachDB