La replicación mantiene un segundo servidor con los mismos datos, aplicando los mismos cambios poco después del primero. Sirve para tres cosas y se despliega con regularidad para una cuarta que no proporciona.

Para qué sirve

  • Capacidad de lectura: los informes y la búsqueda van a la réplica, las escrituras al primario.
  • Copias sin carga: vuelque desde la réplica y el sitio en producción no se entera de nada.
  • Conmutación por fallo: una copia templada lista para promocionarse, que convierte una reconstrucción en un simple cambio.

Lo que no es

Una réplica no es una copia de seguridad. DROP TABLE orders se replica en menos de un segundo y ahora a las dos copias les falta la tabla. Las copias protegen contra errores; las réplicas protegen contra una máquina que muere. Necesita ambas: vea las copias como medida de seguridad.

El retraso que nadie prevé

La replicación es asíncrona por defecto: el primario no espera. Una escritura seguida de inmediato por una lectura en la réplica puede devolver el valor viejo: un cliente guarda su perfil y le aparece sin cambios.

mysql -e "SHOW REPLICA STATUS\G" | grep -E 'Seconds_Behind|Replica_(IO|SQL)_Running'

La regla que lo evita: lea de la réplica solo donde unos datos ligeramente atrasados sean aceptables. Todo lo que el usuario acaba de escribir se lee del primario.

Cómo montarla, a grandes rasgos

  1. Active el registro binario en el primario — log_bin, un server_id único y gtid_mode = ON.
  2. Cree un usuario de replicación — solo con REPLICATION SLAVE.
  3. Siembre la réplica desde un volcado consistente — mysqldump --single-transaction --source-data=2
  4. Apúntela al primario y arránquela — y luego mire el estado hasta que se ponga al día.

Vigílela después

Una réplica parada es silenciosa. Sigue respondiendo lecturas con datos que ya tienen días, lo cual es peor que estar caída. Avise tanto sobre los indicadores de marcha como sobre el retraso.