MySQL en booking

1. MySQL en booking.com Simon J Mudd | 12/09/2013

2. ¿Quién es booking.com? líder mundial en reservas de alojamiento online sede central en Ámsterdam casa matriz, priceline.com, cotiza en NASDAQ alto crecimiento desde su inicio en 1996 trabajamos 24x7x365 – sin downtime

3. ¿Quién soy yo? informático, vivo en España desde hace más que 20 años (5 años en Países Bajos) trabajos anteriores en banca con Sybase trabajo en booking.com desde hace 6 años primer administrador de bases de datos MySQL

4. ¿Esta presentación? La presentación es para hablar de MySQL infraestructura de booking.com como se ha afrontado el gran crecimiento del negocio unas ideas que podrían valer para otros las nuevas versiones de MySQL

5. Nuestra Infraestructura hace 6 años *servidores MySQL y 6 cadenas de replicación sistema operativo CentOS diferenciación de los servidores que daban respuesta a las páginas públicas y las internas configuración manual departamento informático de*personas

6. Nuestra Infraestructura ahora serverdb: sistema de configuración de los equipos propio a través de una página web instalación de sistema operativo con pxeboot, kickstart y puppet instalación y configuración de MySQL con puppet básicamente automático departamento informático de*personas, * DBAs No dejamos de crecer y cambiar

7. Nuestra Infraestructura ahora • LVM – aumentar tamaño de particiones sin downtime • sistema de archivos XFS – robusto • MySQL • solo una instancia de MySQL por servidor • La versión Community (http://dev.mysql.com) • Porque el código fuente está disponible • para resolver problemas puntuales hemos tenido que aplicar parches un par de veces, pero da trabajo de mantenimiento

8. Nuestra Infraestructura ahora • Monitorización con nagios • Graphite recoge información para mostrar en gráficos • Los parámetros del servidor: • Utilización del cpu, memoria, uso de swap, tráfico de red, e/s • Los parámetros de MySQL • SHOW GLOBAL STATUS • Información de InnoDB • … • Guardamos los datos durante al menos un año

9. Hardware • servidores normales. • memoria ha ido ampliándose desde 8 GB hace 6 años hasta 96 GB para las configuraciones normales ahora • 6-8 discos locales con RAID-10 con caché alimentado por batería, absorbe picos de escritura • Espacio utilizable ha subido de 450 GB a 3 TB con discos normales • SAN para los servidores maestro

10. Evolución del número de servidores MySQL

11. Evolución del número de instancias MySQL

12. Capacidad del servidor es insuficiente Supuesto: la carga principal es de lectura (SELECT) Añadir esclavos La configuración de esclavos MySQL es muy fácil hemos tenido hasta 150 esclavos por debajo del mismo servidor maestro límite: ancho de banda de interfaz de red (maestro) y el número de threads utilizados para replicar

13. Capacidad del servidor es insuficiente Maestros: Habilitar binlogs log_bin = ../log/bin_log # camino relativo al datadir sync_binlog = 1 Innobase: ib_logfile– aumentar tamaño para retrasar checkpointing (5.5: 4 GB, 5.6+: más) Esta configuración genera más e/s que un esclavo

14. Capacidad del servidor es insuficiente Replicas: read_only # cuidado con acceso con privilegio SUPER sin binlogs # mejor rendimiento relay_log = ../log/relaylog # camino relativo al datadir 5.5: sync_relay_log (afecta rendimiento) [ una caída puede provocar una perdida de sincronización entre master.info y la base de datos ] 5.6: {master,relay_log}_info_repository = TABLE

15. Capacidad del servidor es insuficiente Replicas: Es importante crear un procedimiento automático para clonar/copiar nuevos esclavos Usar replicas para backups para evitar downtime en el maestro

16. Capacidad del servidor insuficiente Supuesto: la carga principal es de escritura, o la base de datos crece demasiado Separar los datos en dos cadenas de replicación independientes Las aplicaciones tendrán que conectar con las dos cadenas de replicación

17. Capacidad del servidor insuficiente Supuesto: la carga principal es de escritura, y no se puede dividir la base de datos lógicamente • Aplicar SHARDING • Ningún servidor guarda todos los datos • Las aplicaciones tienen que saber dónde encontrar la información y donde escribir sus cambios • La solución más compleja pero necesaria en algunos casos • Se puede replicar los datos vía MySQL o a nivel de aplicación

18. Necesidad de Redundancia Usar múltiples centros de datos toda la configuración de maestro/esclavos duplicada en otro centro de datos el maestro de los otros centros de datos es un esclavo del maestro principal uso de un SAN para guardar los datos en los maestros Tener esclavos de repuesto y usarlos en caso de necesidad

19. Necesidad de Redundancia DC1 DC2 M1 M2 S1 S2 Sn S1 S2 Sn

20. Configuración Guarda toda la configuración que puedas Esto permite saber si algo ha cambiado o ver la evolución de cambios en el tiempo Nuestra memoria no es fiable

21. Configuración Contenido de /etc/my.cnf SHOW GLOBAL VARIABLES Permisos de acceso (GRANTS) estructura de tablas, events, triggers, VIEWsetc tamaño de bases de datos, tablas y archivos utilizados por MySQL configuración de kernel/sysctl–a entradas en el crontab guardar centralmente y normalizar los datos para reducir espacio puede ser bueno para cubrir reglamento legales, auditores

22. Gestión de Permisos (GRANTS) Replicar los permisos de acceso desde el maestro a sus replicos a través de la replicación de la base de datos mysql Un cambio en el maestro llega a todos sus esclavos Es sencillo Es rápido

23. Evitar Retrasos en la Replicación • Solo permite cambios pequeños • Limita el número de filas cambiadas a la vez (máx 10,000) • Las aplicaciones deberían monitorizar los retrasos que pueden provocar y auto-ajustarse • pt-online-schema-change en vez de ALTER TABLE

24. Uso de SSDs Funcionan bien y son rápidos Los usamos en muchos sistemas clave Todavía caras para tamaños grandes No olvidar usar RAID Es el futuro

25. Como actualizar MySQL • Empezar con la actualización de un esclavo y comprueba que funciona bien • copiar la versión actualizada para sustituir servidores con la versión anterior • Actualizar esclavos: • Es fácil de usar otro servidor temporalmente, o • Dejar de usar la replica mientras se actualiza

26. Como actualizar MySQL (2) • Actualizar maestros: es más complejo • construir un nuevo maestro, configurado como esclavo y después mover los esclavos por debajo del nuevo maestro • usar y mover VIP entre antiguo y nuevo • downtime se reduce a un unos segundos • no olvidar que la versión del maestro no puede ser mayor que la versión de sus replicas

27. Como actualizar MySQL (3) Situación Inicial M1a S1 S2 Sn Versión antigua Versión nueva

28. Como actualizar MySQL (3) Actualizar esclavos M1a S1 S2 Sn Versión antigua Versión nueva

29. Como actualizar MySQL (3) Crear un maestro nuevo, configurado como esclavo M1a M1b S1 S2 Sn Versión antigua Versión nueva

30. Como actualizar MySQL (3) Ajustar la configuración de los esclavos para replicar del maestro nuevo M1a M1b S1 S2 Sn Versión antigua Versión nueva

31. Como actualizar MySQL (3) Los clientes hablan con el nuevo maestro M1b S1 S2 Sn Versión antigua Versión nueva

32. Evolución de Versiones MySQL

33. MySQL 5.6 Escritura a disco funciona mejor con más carga performance_schema te dice mejor dónde están los cuellos de botella InnoDB muchas mejoras Para ciertos trabajos puede ser algo más lento que 5.5. Si encuentras una situación así reportarlo como un bug.

34. ¿Qué está haciendo MySQL? Usar graphite o cacti para mostrar las tendencias gráficas Guardar la información al menos un año y con una resolución de 10 segundos Recoger información cada minuto SHOW PROCESSLIST, INNODB STATUS, SLAVE STATUS Sistema Operativo: psauwx, free Guardar información de la última semana Muy útil pero no muestra picos de actividad muy cortos

35. ¿Qué está haciendo MySQL?

36. ¿Qué está haciendo MySQL?

37. ¿Qué está haciendo MySQL? Procesar los binlogs en los maestros Te ayuda a ver dónde está la carga principal (tabla con más cambios en bytes cambiados o número de cambios) Te ayuda a ver los picos que surgen durante el día Te ayuda a ver las causas de retraso en la replicación

38. ¿Qué está haciendo MySQL? pt-table-sync para sincronizar tablas entre instancias

39. ¿Qué está haciendo MySQL?

40. ¿Qué está haciendo MySQL? performance_schema 5.5: Información básica 5.6: Muy bien, aunque la documentación es demasiado técnica no funcional 5.7: va a incluir más información útil: por ejemplo el uso de memoria

41. InnoDB • Úsalo si no lo estás utilizando ya • Más seguro bajo caídas de MySQL o el sistema operativo • No olvidar: • innodb_flush_log_at_trx_commit = 1 • innodb_flush_method = O_DIRECT • evita contención: dividir buffer_pool en 2 GB / max. 64 pools • Cuidado: espacio utilizado en disco es mayor que el utlizado con el motor MyISAM

42. Otras Cosas Controlar acceso: SUPER / read_only Quitar base de datos test y usuarios anónimos La versión de MySQL predeterminada puede ser antigua

43. Herramientas • Perconatoolkit es muy útil • pt-show-grants • pt-diskstats en vez de iostat/vmstat • pt-online-schema-change (algunos cambios tardaron casi una semana en completarse) • pt-table-sync para sincronizar tablas entre instancias

44. Gracias Contacto: simon.mudd@booking.com