Este documento describe cómo lograr alta disponibilidad con réplicas de MySQL en AWS. Explica los problemas comunes como fallos en los nodos de lectura y tareas de mantenimiento. Luego detalla cómo implementar infraestructura tolerante a fallos con HAProxy, ELB, xinetd y Route53 para balancear carga entre réplicas de MySQL y reconectar automáticamente en caso de errores. Finalmente, compara las ventajas de HAProxy frente a ELB y cómo usarlos junto con xinetd para monitorear la disponibilidad y enviar tráfico a los

1. Alta Disponibilidad con
Replicas de MySQL en
AWS
Nicola Strappazzon
nicola@swapbytes.com
@swapbytes

2. Agenda
• Sinopsis
• Los problemas
• Alta Disponibilidad
• Infraestructura
• HAProxy vs ELB
• Xinetd
• ELB & HAProxy & xinetd
• Route53 & HAProxy & xinetd
• Demo
• Preguntas
2

3. Sinopsis
MySQL tiene un gran nivel de flexibilidad,
combinando con otras soluciones poderosas se
obtiene un gran resultado.
Imagina usar Replicas de Lectura, HAProxy, xinetd,
RDS, EC2, Route53 y quien sabe que más… y estar
un poco más tranquilo.
3

4. Los problemas
• La infraestructura:
• Los ELB no funcionan para los RDS Read Replica (Slaves).
• Failover (Retardo, Error 1XXX) de los Slaves
• Tareas de mantenimiento en los Slaves.
• Ataque de tipo DDoS.
• En AWS no tenemos VIP ni Layer 4 del modelo OSI.
• Las aplicaciones:
• Problemas de reconexión.
4

5. Alta Disponibilidad
Un código y una infraestructura tolerante a
fallos es la combinación perfecta.
• Control de errores y acciones correctivas.
• Redundancia del servicio en diferentes zonas.
• El RDS Masted debe tener el MultiAZ activado.
• La aplicación debe reintentar reconectar
automáticamente.
5

6. Infraestructura con ELB
6
Availability Zone C
Availability Zone B
Availability Zone A
HAProxy 02
HAProxy 03
HAProxy 01

7. Infraestructura con Route53
7
Availability Zone C
Availability Zone B
Availability Zone A
HAProxy 02
HAProxy 03
HAProxy 01

8. HAProxy vs ELB
8
HAProxy ELB
High Availability Native No Si
Scalability and Elasticity Manual Dinámico
Timeouts Configurable 60s
Cost Medio Bajo
Server Backup Si No
Usabilidad Experimentada Facil
Downtime <1s 3-10s
Rotar server sin downtime Si No
RDS Si No
EC2 Si Si
Límite de conexiones Si No
Previene DDOS Attack Si No
Checks Por Server Global

9. Xinetd
• Se usa para informar al HAProxy y al ELB usando
HTTP, 200 OK / 503 KO.
• Es un servicio que se ejecuta en la EC2 destinada
al HAProxy.
• Cada puerto representa un check, algunos para el
HAProxy, otros para el ELB.
9
eXtended InterNET Daemon

10. ELB + HAProxy + xinetd
• El servicio Xinetd debe tener una serie de checks que
indican:
- Al ELB si el HAProxy está disponible.
Ej: El HAProxy esta activo, pero no hay ningún servicio disponible, entonces el
Xinetd informa al ELB que no esta disponible.
- Al HAProxy tiene algún servicio disponible.
Ej: Hay algún servicio que no está disponible para el HAProxy y se inactiva.
• Si la EC2 no está disponible, el ELB no le envía trafico.
• No hay forma de quitar una EC2 del ELB de forma
transparente.
La unión es la fuerza
10

11. Route53 + HAProxy + xinetd
• El servicio Xinetd debe tener una serie de checks que
indican:
- Al HAProxy tiene algún servicio disponible.
Ej: Hay algún servicio que no está disponible para el HAProxy y se inactiva.
• Si el HAProxy no está disponible, Route53 sigue enviando
trafico.
• Si la EC2 no está disponible, Route53 no envía trafico.
• Agregar o quitar un HAProxy es transparente por el TTL.
La unión es la fuerza
11

12. Demo
12

13. Preguntas
13

14. Gracias
14