Replicación de bases de datos - Logrando disponibilidad y escalabilidad

15 min de lectura | 2025.12.15

¿Qué es la replicación?

La replicación (Replication) es un mecanismo que copia y sincroniza datos de una base de datos en múltiples servidores. Se utiliza para mejorar la disponibilidad, el rendimiento de lectura y la recuperación ante desastres.

¿Por qué es necesaria?: Un único servidor de base de datos se convierte en un punto único de fallo (SPOF). Con la replicación, el servicio puede continuar durante fallos y las consultas de lectura pueden distribuirse.

Configuración básica de replicación

Maestro-Esclavo (Primario-Réplica)

flowchart TB
    M["Master (Primary)<br/>← Escritura"]
    M -->|Replicación| S1["Slave 1 (Replica)<br/>← Lectura"]
    M -->|Replicación| S2["Slave 2 (Replica)<br/>← Lectura"]
    M -->|Replicación| S3["Slave 3 (Replica)<br/>← Lectura"]
  • Master (Primary): Servidor principal que acepta escrituras
  • Slave (Replica): Copia datos del maestro y maneja lecturas

Multi-maestro

flowchart LR
    M1["Master 1"] <-->|Replicación| M2["Master 2"]
    M1 --> RW1["Lectura/Escritura"]
    M2 --> RW2["Lectura/Escritura"]

Múltiples maestros aceptan escrituras. La resolución de conflictos es un desafío.

Replicación síncrona vs asíncrona

Replicación síncrona

sequenceDiagram
    participant C as Cliente
    participant M as Master
    participant S as Slave
    C->>M: Escritura
    M->>S: Replicación
    S->>M: ACK
    M->>C: Respuesta
VentajasDesventajas
Sin pérdida de datosAumento de latencia
Consistencia fuerteEscritura detenida si el esclavo falla

Replicación asíncrona

sequenceDiagram
    participant C as Cliente
    participant M as Master
    participant S as Slave
    C->>M: Escritura
    M->>C: Respuesta
    M-->>S: Replicación (aplicada después)
VentajasDesventajas
Baja latenciaRetraso de replicación
Sin impacto por fallo del esclavoPosible pérdida de datos

Replicación semi-síncrona

El commit se confirma cuando al menos un esclavo ha recibido los datos.

sequenceDiagram
    participant C as Cliente
    participant M as Master
    participant S1 as Slave 1
    participant S2 as Slave 2
    C->>M: Escritura
    M->>S1: Replicación
    S1->>M: ACK
    M->>C: Respuesta
    M-->>S2: Replicación (aplicada después)

Métodos de replicación

Basada en sentencias

Replica las sentencias SQL mismas.

-- Ejecutado en el maestro
INSERT INTO users (name, created_at) VALUES ('Alice', NOW());

-- Se ejecuta el mismo SQL en el esclavo
-- Problema: El resultado de NOW() puede diferir

Basada en filas

Replica los datos de las filas modificadas.

flowchart LR
    Before["{id: 1, name: 'Alice'}"] --> Change["Cambio"] --> After["{id: 1, name: 'Bob'}"]
    After --> Apply["Aplicar esta diferencia al esclavo"]

Modo mixto

Normalmente usa basada en sentencias, y basada en filas cuando incluye funciones no determinísticas.

Retraso de replicación

Es el retraso hasta que el esclavo alcanza al maestro.

flowchart LR
    subgraph Master["Maestro"]
        MT["Transacción 1, 2, 3, 4, 5 ✓"]
    end
    subgraph Slave["Esclavo (retraso: 2 transacciones)"]
        ST["Transacción 1, 2, 3 ✓"]
    end
    Master -.-> Slave

Casos donde el retraso es problemático

// Lectura inmediatamente después de escribir
await db.master.query('UPDATE users SET name = ? WHERE id = ?', ['Bob', 1]);

// Lectura desde el esclavo → Pueden devolverse datos antiguos
const user = await db.slave.query('SELECT * FROM users WHERE id = ?', [1]);
// ¡user.name todavía es 'Alice'!

Contramedidas

  • Read Your Writes: Leer del maestro inmediatamente después de escribir
  • Causal Consistency: Rastrear timestamp de escritura
  • Replicación síncrona: Solo para datos críticos

Failover

Cuando el maestro falla, un esclavo se promueve a maestro.

Failover automático

flowchart TB
    A["1. Detección de fallo del maestro<br/>El sistema de monitoreo detecta que el maestro no responde"]
    B["2. Selección del esclavo<br/>Se selecciona el esclavo con la replicación más avanzada"]
    C["3. Proceso de promoción<br/>El esclavo seleccionado se promueve a maestro"]
    D["4. Conmutación<br/>La conexión de la aplicación se cambia al nuevo maestro"]
    A --> B --> C --> D

Consideraciones durante el failover

DesafíoContramedida
Split-brainFencing (forzar detención del maestro antiguo)
Pérdida de datosTransacciones no aplicadas en replicación asíncrona
Conmutación de conexionesIP virtual, actualización DNS, proxy

Implementaciones representativas

MySQL

-- Configuración del maestro
CHANGE MASTER TO
  MASTER_HOST='master.example.com',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=4;

START SLAVE;

PostgreSQL

# postgresql.conf (maestro)
wal_level = replica
max_wal_senders = 3

# recovery.conf (esclavo)
standby_mode = 'on'
primary_conninfo = 'host=master.example.com port=5432'

Servicios administrados

ServicioFunción de réplica
Amazon RDSRead Replica, Multi-AZ
Cloud SQLRead Replica, Configuración de alta disponibilidad
Azure SQLgeo-replication

Patrón de escalado de lectura

flowchart LR
    App["App"]
    App --> M["Master<br/>(Escritura)"]
    App --> LB["Load Balancer"]
    LB --> R1["Replica 1"]
    LB --> R2["Replica 2"]
    LB --> R3["Replica 3"]

    subgraph Read["Lectura"]
        R1
        R2
        R3
    end

Las consultas de lectura se distribuyen a las réplicas a través del balanceador de carga.

Resumen

La replicación de bases de datos es una tecnología fundamental para lograr alta disponibilidad y escalabilidad de lectura. Diseñando adecuadamente la elección entre síncrona/asíncrona, el manejo del retraso de replicación y la estrategia de failover, se pueden construir sistemas de bases de datos robustos.

← Volver a la lista