Arostik Logo
ArostikVLARCK

Micro-Technology Solutions

Bases de DatosNivel: Avanzado15 min de lección

Replicación de Bases de Datos: Primario-Secundario y Alta Disponibilidad

Cómo configurar réplicas de lectura, replicación sincrónica vs asincrónica y failover automático para que tu sistema nunca se detenga.

Replicación de Bases de Datos: Primario-Secundario y Alta Disponibilidad
AROS STUDENT
E
Equipo de Arquitectura de Datos ArostikEspecialistas en Alta Disponibilidad y Resiliencia · Actualizado el 25 sep 2026
¿Qué es la Replicación de Bases de Datos?

Si tienes toda la base de datos de tu empresa en un único servidor y la placa madre se quema, la memoria RAM falla o el disco duro se corrompe, tu negocio queda fuera de línea de inmediato y corres el riesgo de perder transacciones valiosas. La **Replicación de Bases de Datos** es la técnica mediante la cual los datos registrados en un servidor principal (**Primario o Master**) se copian de forma continua y automatizada hacia uno o más servidores secundarios (**Réplicas o Standbys**) conectados a través de la red. En la arquitectura estándar de la industria (Primary-Replica con Réplicas de Lectura): - **El Servidor Primario** es el único que procesa operaciones de escritura (`INSERT`, `UPDATE`, `DELETE`). - **Las Réplicas Secundarias** reciben el flujo de cambios en tiempo real y atienden el 90% de las consultas de solo lectura (`SELECT`), multiplicando la capacidad del sistema y estando listas para convertirse en el nuevo primario si el original muere (**Failover**).

¿Cuáles son los Beneficios Críticos de Tener Réplicas?
Ventajas y Beneficios:
  • ✓Alta Disponibilidad (High Availability - HA): Si el servidor primario explota, una réplica asume el rol en menos de 10 segundos con mínima o nula interrupción de servicio.
  • ✓Escalabilidad Masiva de Lecturas (Read Scalability): Puedes conectar 5 réplicas secundarias para absorber millones de consultas `SELECT` simultáneas de reportes y catálogo.
  • ✓Copias de Respaldo sin Impacto en Producción: Puedes ejecutar `pg_dump` o respaldos pesados sobre una réplica secundaria sin ralentizar las compras de los clientes en el primario.
Problemas que resuelve:
  • •Elimina el temido punto único de fallo (SPOF) en la capa de persistencia de datos.
  • •Protege contra desastres geográficos manteniendo réplicas en diferentes regiones o proveedores de nube.
  • •Permite realizar mantenimiento o actualizaciones de hardware en servidores sin apagar el servicio web.
El Escribano Real y los Copistas de la Biblioteca

Imagina un reino medieval donde se redactan las leyes reales: - **El Escribano Real (El Servidor Primario)**: Es el único hombre en todo el reino autorizado a escribir leyes nuevas o modificar decretos con su pluma dorada en el Libro de Oro. Nadie más puede escribir en él. - **Los Copistas (Las Réplicas de Lectura)**: Sentados al lado del escribano hay cuatro copistas veloces. Cada vez que el escribano escribe una frase en el Libro de Oro, los copistas copian la misma frase en sus propios libros de réplica en un segundo. Cuando 500 campesinos llegan a la biblioteca a leer las leyes, leen los libros de los copistas para no molestar al escribano. Si el escribano real se enferma o fallece, el copista más experimentado toma la pluma dorada y es coronado inmediatamente como el nuevo Escribano Real (Failover automático).

Conexión con la Tecnología:El flujo de tinta es el **WAL (Write-Ahead Logging)** en PostgreSQL o el **Binlog** en MySQL. Cada cambio registrado en el log de transacciones se transmite por un socket TCP a las réplicas para que apliquen los mismos bytes.

Explicación Paso a Paso del Tema

1

Replicación Sincrónica vs Asincrónica

Debes entender el compromiso fundamental entre velocidad y riesgo de pérdida de datos: - **Asincrónica (Predeterminada)**: El primario escribe el dato en su disco local, confirma el éxito al usuario de inmediato y envía el cambio a la réplica en segundo plano. Si el primario se quema en ese milisegundo exacto, puede haber una pequeña pérdida de datos (**Replication Lag**). - **Sincrónica**: El primario espera a que al menos una réplica confirme haber grabado el cambio en su disco antes de responderle al usuario. Cero pérdida de datos (RPO = 0), pero la velocidad de escritura queda limitada por la latencia de la red.

Consejo Profesional:

La mayoría de las plataformas usan replicación asincrónica para lecturas y una réplica sincrónica local para alta disponibilidad estricta.

2

Inspeccionar el Estado de la Replicación en PostgreSQL

Ejecuta una consulta sobre la vista del sistema `pg_stat_replication` en el servidor primario para verificar el retardo (lag) y la salud de las réplicas conectadas.

Verás las IPs de las réplicas, su modo de sincronización y cuántos bytes de retraso tienen.

Comando de Terminal / Código
SELECT client_addr, state, sync_state, sync_priority,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes
FROM pg_stat_replication;
Desglose de Parámetros:
Parámetro / FlagTipo / RolSignificado y Uso
pg_stat_replicationVista del SistemaMuestra detalles en vivo de los procesos WAL sender conectados a réplicas.
lag_bytesCálculoDiferencia en bytes entre lo escrito en el primario y lo replicado en la secundaria.
Error Común a Evitar:

Tener un 'Replication Lag' de minutos debido a una red lenta: si un usuario escribe un comentario en el primario e inmediatamente recarga la página leyendo de una réplica rezagada, creerá que su comentario se borró.

3

Failover Automático con Patroni y Raft/etcd

Nunca hagas failover a mano si necesitas alta disponibilidad empresarial.

Herramientas de orquestación como **Patroni** utilizan un almacén de consenso distribuido (etcd o Consul con algoritmo Raft) para monitorear el clúster. Si el primario no emite latido en 5 segundos, el clúster elige democráticamente a la mejor réplica y la promueve a primario de forma transparente sin intervención humana.

Consejo Profesional:

Evita a toda costa el fenómeno del 'Split-Brain' (donde dos servidores creen que ambos son el primario al mismo tiempo). Un clúster de quórum con al menos 3 nodos de etcd garantiza que solo un nodo pueda tener la pluma de escritura.

Casos Prácticos Reales en Producción

Situaciones de ingeniería reales sin mención de presupuestos ficticios.

1La Falla de Hardware que no Provocó Caída en una Pasarela de Pagos

Escenario Real:

A las 3:00 AM, la memoria RAM del servidor primario de base de datos de un banco sufrió un error físico irrecuperable y la máquina se apagó al instante.

Solución de Ingeniería Aplicada:

El clúster administrado con Patroni detectó la pérdida de señal en 3 segundos. Promovió la réplica sincrónica a nuevo Primario y reconfiguró el balanceador HAProxy para apuntar las escrituras a la nueva IP.

Fichas Nemotécnicas de Conceptos Clave

Glosario rápido para recordar los términos fundamentales de la lección.

WAL (Write-Ahead Logging)

Mecanismo fundamental de persistencia que registra todos los cambios en un registro binario secuencial antes de aplicarlos a los archivos de datos.

Failover

Procedimiento de emergencia automático mediante el cual una réplica secundaria asume el rol de servidor primario ante la caída del original.

Split-Brain

Estado catastrófico donde dos servidores en una red particionada creen que ambos son el primario simultáneamente, corrompiendo los datos.

Autoevaluación Rápida3 preguntas

Replicación de Bases de Datos: Primario-Secundario y Alta Disponibilidad

Selecciona una opción para autoevaluarte al instante. La respuesta se califica de inmediato.

Aciertos: 0 / 3
1

En una arquitectura estándar de Replicación Primario-Secundario (Master-Slave), ¿qué servidor tiene permiso para ejecutar sentencias de escritura (INSERT, UPDATE)?

2

¿Qué es el 'Replication Lag' (Retardo de Replicación)?

3

¿Qué grave problema previene el uso de algoritmos de quórum y consenso (como Raft/etcd) durante un failover automático?

Preguntas Frecuentes (FAQ)

¿Qué diferencia hay entre replicación física y replicación lógica en PostgreSQL?

La replicación física copia el clúster completo bit por bit a través de los archivos WAL (idéntica versión de SO y PostgreSQL). La replicación lógica transmite cambios a nivel de tablas específicas mediante eventos de publicación y suscripción, permitiendo replicar entre diferentes versiones de PostgreSQL o hacia sistemas de analítica externos.

¿Qué es Multi-Master Replication?

Es una arquitectura avanzada donde múltiples nodos pueden recibir escrituras concurrentes simultáneamente. Es mucho más compleja de mantener debido a la necesidad de resolver conflictos de escritura en tiempo real cuando dos usuarios modifican la misma fila en servidores distintos a la vez.

Temas relacionados:#Bases de Datos#Replicación#PostgreSQL#Alta Disponibilidad#DevOps