WordPress + Replicación MySQL

Cuándo necesitas replicación

La replicación MySQL mantiene una copia en un segundo servidor. Escrituras al primario. Lecturas desde cualquiera.

WordPress se beneficia en tres escenarios:

1. Alto tráfico de lectura — 10x más SELECT que INSERT/UPDATE.

2. Backups sin interrumpir producción — backup desde réplica sin lockear primario.

3. Recuperación de desastres — si primario muere, promueve réplica.

Para sitios bajo 1M visitas mensuales, la replicación es overkill. Para sitios con 10M+ visitas o SLA estricto, es esencial.

La arquitectura

[Visitantes] → [Load Balancer]
                    │
            ┌───────┴───────┐
            │               │
       [Web Server 1]  [Web Server 2]
            │               │
            └───────┬───────┘
                    │
            ┌───────┴───────┐
            │               │
       [MySQL Primario] ──→ [MySQL Réplica]
       (escrituras)         (solo lecturas)

Configurando replicación básica

Paso 1 — En el primario

/etc/mysql/my.cnf:

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_format = ROW
expire_logs_days = 7
binlog_do_db = your_wp_database

Reinicia MySQL.

Crea usuario de replicación:

CREATE USER 'replica'@'%' IDENTIFIED BY 'StrongPassword123!';
GRANT REPLICATION SLAVE ON *.* TO 'replica'@'%';
FLUSH PRIVILEGES;

Lockea y anota posición:

FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
-- Anota File y Position

En otra terminal:

mysqldump --single-transaction --master-data your_wp_database > primary-dump.sql

Desbloquea:

UNLOCK TABLES;

Paso 2 — En la réplica

/etc/mysql/my.cnf:

[mysqld]
server-id = 2
relay_log = /var/log/mysql/mysql-relay-bin.log
read_only = 1

Reinicia. Importa dump:

mysql your_wp_database < primary-dump.sql

Configura replicación:

CHANGE MASTER TO
  MASTER_HOST='primary.yoursite.com',
  MASTER_USER='replica',
  MASTER_PASSWORD='StrongPassword123!',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=12345;

START SLAVE;

Paso 3 — Verifica

SHOW SLAVE STATUS\G

Busca: - Slave_IO_Running: Yes - Slave_SQL_Running: Yes - Seconds_Behind_Master: 0

Apuntando WordPress a la réplica

Opción 1: HyperDB

Plugin gratis de Automattic. Configura wp-content/db-config.php:

$wpdb->add_database(array(
    'host'     => 'primary.yoursite.com',
    'user'     => DB_USER,
    'password' => DB_PASSWORD,
    'name'     => DB_NAME,
    'write'    => 1,
    'read'     => 1,
));

$wpdb->add_database(array(
    'host'     => 'replica.yoursite.com',
    'user'     => DB_USER,
    'password' => DB_PASSWORD,
    'name'     => DB_NAME,
    'write'    => 0,
    'read'     => 2,
));

Coloca wp-content/db.php de HyperDB.

Opción 2: ProxySQL

Los servidores web conectan a ProxySQL. ProxySQL enruta:

INSERTs → primario
SELECTs → réplica

Cero cambios de código WordPress.

Gotchas

Lag de replicación

La réplica siempre está ligeramente atrás. HyperDB pinea sesiones de usuario al primario brevemente tras escrituras.

Cambios de schema

ALTER TABLE en primario replica. Para tablas grandes, causa minutos de lag. Usa pt-online-schema-change (Percona Toolkit).

Backups

Usa réplica para mysqldump:

mysql -e "STOP SLAVE; FLUSH TABLES WITH READ LOCK;"
mysqldump --all-databases > /backup/full-dump.sql
mysql -e "UNLOCK TABLES; START SLAVE;"

O mariabackup (sin lock):

mariabackup --backup --target-dir=/backup/

Promoviendo réplica a primario

Si primario falla:

STOP SLAVE;
RESET MASTER;
SET GLOBAL read_only = 0;

Actualiza WordPress para apuntar a réplica.

Monitoreando salud de replicación

Métrica crítica: Seconds_Behind_Master.

*/5 * * * * /var/www/yoursite/scripts/check-replication.sh

#!/bin/bash
LAG=$(mysql -BNe "SHOW SLAVE STATUS\G" | grep "Seconds_Behind_Master:" | awk '{print $2}')
if [ "$LAG" -gt 30 ]; then
    echo "MySQL lag: $LAG seconds" | mail -s "ALERTA REPLICACION" admin@yoursite.com
fi

Cuándo NO usar replicación

Sitio WordPress pequeño (< 100K visitas mensuales): la complejidad no vale
Sitios sin lógica de read/write split: pagas por réplica sin beneficio
Sitios con consistencia estricta: usa replicación sincrónica (Galera Cluster)

Alternativa: replicación gestionada

AWS RDS, Azure Database, Google Cloud SQL ofrecen réplicas de lectura con un clic. Para la mayoría de operaciones WordPress, mucho más simple que self-managing.

Costo más alto pero complejidad operacional cae a casi cero.

Errores comunes

Replicar sin binlog_format = ROW — formato STATEMENT se rompe
No configurar read_only en réplica — escrituras accidentales rompen replicación
Olvidar instalar db.php durante setup HyperDB — silenciosamente lo deshabilita
Sin monitoreo de lag — la réplica se queda atrás, nadie nota

Cuándo llamar a un especialista

Hemos configurado docenas de topologías de replicación WordPress. Para la mayoría de sitios, recomendamos réplicas RDS gestionadas — TCO más bajo.

Consulta escalado de base de datos. Para infraestructura más amplia ve soporte de emergencia.