El equipo "añade replicación para mejorar el rendimiento". Dos meses después: maestro saturado, réplica inactiva con un 4 % de CPU, el presupuesto se duplicó. Otro escenario: conmutación por error “automática” activada: la aplicación aún escribe en la antigua dirección IP del maestro falla; veinte minutos de indisponibilidad.
La replicación resuelve un problema bien planteado:
- Disponibilidad (sobrevivir a la muerte del maestro)
- Aumento de carga de lectura (desconexión de carga de SELECT)
- Reportes (analítico sin matar la producción)
- Proximidad geográfica (lectura local, con consistencia débil)
Elegir "réplica porque es profesional" sin enrutamiento de lectura = coste más complejidad sin ganancia.
Matriz objetiva → arquitectura
| Objetivo | Modelo | Trampa |
|---|---|---|
| Alta disponibilidad | Primario + reserva síncrona/semisincrónica + Patroni | Cerebro dividido no probado |
| Ampliar la lectura | Réplicas asincrónicas + proxy de lectura/escritura | Cambio UX posterior a la escritura |
| Copia de seguridad en vivo | Réplica retrasada | No reemplaza una copia de seguridad probada |
| Lectura geográfica | Réplica regional | Conflictos de coherencia |
Una réplica no es una copia de seguridad: la corrupción lógica también se replica.
Retraso en la replicación y experiencia del usuario web
Después del registro:
// POST maestro → redirigir GET /perfil
// OBTENER en la réplica → el usuario aún no es visible si el retraso es 2
Soluciones:
- Leer tus propias escrituras: sesión fija en el maestro N segundos después de la escritura.
- Proxy: ProxySQL, PgBouncer con enrutamiento inteligente.
- CQRS: acepta la posible coherencia en el lado de la interfaz.
MySQL vs PostgreSQL: vista de explotación
MySQL: binlog asíncrono/semisincrónico; leer réplicas; Cambio MHA/Orquestador.
PostgreSQL: replicación de streaming; espera activa en lectura; Cambio de patroni + etcd.
Base de datos gestionada (RDS, Cloud SQL, OVH DB): Multi-AZ ≠ leer réplica — lea la documentación del producto. Para elegir el alojamiento, consulte VPS o nube y el directorio.
Cuando una réplica en el mismo host es suficiente (o no)
| Cargar | Recomendación |
|---|---|
| Blog, pequeño SaaS | Instancia única más copias de seguridad probadas |
| Lectura >> escritura medida | Una o dos réplicas de lectura |
| Acuerdo de Nivel de Servicio 99,9%+ | Gestionado equipo de alta disponibilidad o Patroni |
| Análisis pesados | Réplica dedicada al reportaje |
Una réplica en el mismo servidor físico (algunas ofertas compartidas o de nivel básico) es una ilusión de alta disponibilidad: falla de hardware, falla de ambos. Antes de agregar una réplica, mida la proporción de lectura/escritura con pg_stat_statements o su herramienta de monitoreo de aplicaciones: un maestro mal indexado seguirá siendo lento incluso con tres réplicas sin usar.
Lo mejor: replicar datos duplicados: no disponibilidad sin pruebas
Esto es lo que la diapositiva de "alta disponibilidad" olvida mostrar.
Presupuesto: ejercicio de transición trimestral > tercera réplica no utilizada.
Decide y avanza sin puntos ciegos
Antes de agregar una réplica, indique el objetivo en una oración:
- Formule el objetivo: alta disponibilidad, lectura, informes o geografía.
- Mida la relación lectura/escritura de las rutas de su aplicación.
- Explícitamente enrute los SELECT si la carga de lectura aumenta.
- Monitorear el retraso y las alertas más allá del umbral comercial.
- Probar la conmutación por error documentada al menos trimestralmente.
Una réplica sin enrutamiento de lectura ni ejercicio de conmutación por error es una línea presupuestaria, no un seguro. Cruce con EXPLAIN PostgreSQL para optimizar el maestro antes de duplicarlo.
Preguntas frecuentes
¿Una réplica de lectura acelera automáticamente mi sitio?
Solo si enruta explícitamente SELECT a la réplica y la carga se lee principalmente. Si todo pasa por el maestro, la réplica permanece inactiva e inútil para el rendimiento.
¿Qué es el retraso de replicación?
Este es el retraso entre la confirmación en el maestro y la visibilidad en la réplica. Un retraso de unos segundos puede hacer que desaparezcan temporalmente los datos que un usuario acaba de escribir.
¿Replicación síncrona o asíncrona?
Synchronous limita la pérdida de datos pero aumenta la latencia de escritura. Asíncrono mejora el rendimiento de escritura a costa de un riesgo de pérdida si el maestro muere antes de la propagación.
¿Está el interruptor automático listo para usar?
No. Requiere un orquestador, pruebas periódicas y gestión del cerebro dividido. El DNS o la dirección virtual deben cambiar al nuevo maestro; nada es automático sin configuración y ejercicio.
Replicar sin objetivo significa pagar dos veces por la misma consulta mal indexada en el maestro.