MySQL en booking

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


● 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


● 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


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


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


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


M1a

S1 S2 Sn


Actualizar esclavos

29


M1a

S1 S2 Sn


M1bCrear un maestro nuevo,configurado como esclavo

30


M1a

S1 S2 Sn


M1bAjustar la configuraciónde los esclavos parareplicar del maestro nuevo

31


S1 S2 Sn


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


36


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


38

pt-table-sync para sincronizar tablas entre instancias


39


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


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

44

Gracias

Contacto:● [email protected]

Documents

MySQL en booking