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
Nov-0
5
Jan-
06
Mar
-06
May
-06
Jul-0
6
Sep-0
6
Nov-0
6
Jan-
07
Mar
-07
May
-07
Jul-0
7
Sep-0
7
Nov-0
7
Jan-
08
Mar
-08
May
-08
Jul-0
8
Sep-0
8
Nov-0
8
Jan-
09
Mar
-09
May
-09
Jul-0
90%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
11
Evolución del número de instancias MySQL
01/1
2/20
05
01/0
2/20
06
01/0
4/20
06
01/0
6/20
06
01/0
8/20
06
01/1
0/20
06
01/1
2/20
06
01/0
2/20
07
01/0
4/20
07
01/0
6/20
07
01/0
8/20
07
01/1
0/20
07
01/1
2/20
07
01/0
2/20
08
01/0
4/20
08
01/0
6/20
08
01/0
8/20
08
01/1
0/20
08
01/1
2/20
08
01/0
2/20
09
01/0
4/20
09
01/0
6/20
09
01/0
8/20
090
10
20
30
40
50
60
70
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
M1
S1 S2 Sn
DC1
M2
S1 S2 Sn
DC2
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, VIEWs etc● 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)
M1a
S1 S2 Sn
Versión nueva Versión antigua
Situación Inicial
28
Como actualizar MySQL (3)
M1a
S1 S2 Sn
Versión nueva Versión antigua
Actualizar esclavos
29
Como actualizar MySQL (3)
M1a
S1 S2 Sn
Versión nueva Versión antigua
M1bCrear un maestro nuevo,configurado como esclavo
30
Como actualizar MySQL (3)
M1a
S1 S2 Sn
Versión nueva Versión antigua
M1bAjustar la configuraciónde los esclavos parareplicar del maestro nuevo
31
Como actualizar MySQL (3)
S1 S2 Sn
Versión nueva Versión antigua
M1bLos clientes hablan con el nuevo maestro
32
Evolución de Versiones MySQL
12/200503/200606/200609/200612/200603/200706/200709/200712/200703/200806/200809/200812/200803/200906/20090%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
5.05.15.55.6
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: ps auwx, 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
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
¿Qué está haciendo MySQL?
38
pt-table-sync para sincronizar tablas entre instancias
¿Qué está haciendo MySQL?
39
¿Qué está haciendo MySQL?
40
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
¿Qué está haciendo MySQL?
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● Percona toolkit 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
Recommended