Ir al contenido
EuroVPSEuroVPS

Qué hacemos · Datos y web: Replicación de bases de datos y réplicas en otra sede

Réplicas MySQL y MariaDB con GTID en una segunda sede, traídas por una malla privada cifrada, monitorizadas cada cinco minutos, listas para informes o failover.
Fibra peinada en un switch Cisco Nexus

Una copia de solo lectura, actualizada de forma continua, de su base de datos de producción, funcionando en una sede distinta, donde los informes pueden ejecutarse sin tocar producción y a la que puede conmutar si la sede primaria se pierde alguna vez. Construida de modo que la réplica entra a buscar los cambios, y producción nunca tiene un camino de salida hacia ella.

Qué es

Replicación asíncrona de MySQL o MariaDB, con la réplica situada donde un fallo distinto no pueda alcanzarla: otro datacenter, otra cabina de storage, otra ruta de red. La réplica sigue a la primaria casi en tiempo real, y cumple tres funciones a la vez:

  • Una copia de disaster recovery de los datos, actualizada a segundos.
  • Un destino para informes e integraciones, para que los trabajos de lectura pesados dejen de competir con sus clientes.
  • Un origen limpio para los backups, tomados sin bloquear ni ralentizar la primaria.

Cómo lo construimos

La réplica hace pull. Las conexiones de replicación las abre la réplica, nunca al revés. Producción no tiene ninguna ruta de red hacia el lado de la réplica, y eso se impone en los appliances de firewall, no con una regla de host que alguien pueda apagar. Si un servidor de producción llega a verse comprometido, el atacante no tiene ruta hacia la copia desde la que usted se recuperaría.

Por nuestra malla privada. Las réplicas en otra sede viajan por nuestro backbone privado cifrado entre nuestros datacenters de Atenas, Ámsterdam y Toronto, nunca en claro por la internet pública.

Basada en GTID. Usamos identificadores globales de transacción, de modo que una réplica puede reapuntarse, promoverse o resembrarse sin que nadie tenga que buscar coordenadas de binary log a las tres de la madrugada.

Monitorizada por estado, no por ruido. Una comprobación se ejecuta cada cinco minutos y publica una sola alerta cuando el estado cambia: retraso por encima del umbral, rota o recuperada. Los ingenieros reciben una señal sobre la que actúan, no un flujo que aprenden a ignorar.

De qué le protege

  • Perder una sede entera y, con ella, la única copia de sus datos.
  • Consultas de informes e integraciones que ralentizan la base de datos que usan sus clientes.
  • Una réplica que dejó de funcionar en silencio hace semanas, descubierta solo el día en que la necesita.
  • Un atacante en un servidor de producción que alcanza la copia desde la que restauraría.
  • Backups que bloquean tablas o detienen la primaria mientras se ejecutan.

En la práctica

La salida de VMware de una cadena de televisión. Cuando reconstruimos la plataforma web de una cadena de televisión nacional sobre nuestro private cloud OLVM, la base de datos era el único nivel que llevaba un estado que mereciera la pena mover. Viajó por replicación GTID de la plataforma antigua a la nueva, de modo que el cutover en sí fue una promoción con segundos de diferencia. El cutover se completó hace meses y la plataforma funciona en nuestro lado desde entonces.

Réplicas que sirven a aplicaciones nuevas. Una réplica de lectura es también la forma más limpia de poner un nuevo buscador, un sistema de informes o un portal encima de un sistema existente: la aplicación nueva lee a velocidad de red local y nunca toca la primaria durante la carga de páginas. Las construimos iniciadas por la réplica, de modo que el host que la aloja no necesita ninguna regla de firewall de entrada.

Por qué EuroVPS

  • Las réplicas viven en una sede realmente distinta, unida por nuestro propio backbone cifrado.
  • Solo pull, impuesto por el firewall: producción nunca puede alcanzar el lado de la réplica.
  • Alertas por cambio de estado cada cinco minutos, leídas por ingenieros las veinticuatro horas.
  • GTID en todo, de modo que la promoción y la resiembra son procedimientos ensayados.
  • El mismo equipo construye la réplica, los backups y el plan de failover, para que encajen entre sí.

Preguntas frecuentes

  1. ¿Cuánto retraso tendrá la réplica? Con carga normal, segundos o menos. Alertamos cuando el retraso cruza un umbral que acordamos con usted, y el RPO que obtiene sigue al servicio que contrata.
  2. ¿Podemos conmutar a la réplica? Sí. La promoción es un procedimiento documentado. La rapidez con que las aplicaciones la siguen depende del diseño del servicio, desde una promoción manual para un servicio básico hasta un switchover automatizado y ensayado para los de cobertura global.
  3. ¿Puede conectarse a ella nuestra herramienta de informes? Sí, con una cuenta de solo lectura. Es una de las principales razones para tenerla.
  4. ¿Sustituye a los backups? No. Una réplica copia los errores con la misma fidelidad que los datos. Los backups se toman junto a ella y se traen por pull a una infraestructura separada.
  5. ¿MySQL o MariaDB? Ambos. Ajustamos el motor y la configuración de la réplica a los de la primaria.

¿Quiere una copia de sus datos que un mal día no pueda alcanzar? Hable con un ingeniero.

Su próximo socio de infraestructura

Veamos su infraestructura.

Cuéntenos qué ejecuta hoy y qué necesita mejorar. Un ingeniero revisará su solicitud y le ayudará a planificar el siguiente paso.

+357 222 32280
Un ingeniero de EuroVPS transporta un nodo de servidor en la sala del datacenter
Una conversación con las personas que cuidarán de su infraestructura.

Empecemos por su infraestructura.

Un poco de contexto nos ayuda a empezar la conversación adecuada.

Usaremos sus datos para responder a su consulta. Política de privacidad