Alternativas de alta disponiblidad en MySQL - MySQL Meetup - Montevideo - Marzo 2012

Alternativas de HA en MySQL
Ing. Nelson Calero, OCP
nelson.calero@gmail.com

MySQL Meetup Montevideo
8 de Marzo 2012
1 /47

Conceptos

Disponibilidad

• Porcentaje de tiempo en que un sistema/recurso está
disponible para ser usado
A = uptime/(uptime + downtime)

• Medida con escala de nueves:
99% => 3 días, 15:36 horas /año
99,9% => 8:46 horas/año o 43.8 minutos/mes
99,99% => 53 minutos/año o 4.38 minutos/mes
99,999% => 5 minutos/año o 0.44 minutos/mes

2/47

Conceptos - Disponibilidad

• Capacidad de continuar trabajando a pesar de fallas
(hardware, software, externas).

Siendo más formales:
• Mean Time Between Failures (MTBF)
Tiempo medio estimado entre fallas.
• Mean Time to Repair/Recover (MTTR)
Tiempo medio para reparar las fallas

Equivalente: A = MTBF / (MTBF + MTTR)

En un sistema, podemos diseñar la arquitectura para que altos
tiempos de MTTR en componentes no afecten la
disponibilidad total del sistema.
3/47

Soluciones de HA en MySQL

Hay varias posibilidades nativas:
– Replicación
– Storage compartido
– Cluster

Y varias provistas por terceros:
– MMM: Multi Master replication Manager for MySQL.
– DRBD: replicación sincrónica de bloques usando la red
– Pacemaker: Cluster resource manager
– Galera: replicación sincrónica – parche
– Tungsten: replicación a nivel de aplicación

4/47

MySQL - Replicación

Basada en transferencia y aplicación de Log Binario del master
a slaves, en forma asincrónica o semisincrónica (5.5).

• es en un sólo sentido (one-way)
• un slave puede tener un solo master
• por sentencias, registros cambiados (5.1), o mixto
• puede ser parcial, filtrando por base y tablas
• controlada por parámetros en my.cnf y comandos para
configuración dinámica
• cluster implementa replicación sincrónica

Dos thread en cada slave:
• obtiene registros de binlog y genera relaylog (I/O thread)
• lee relaylog y aplica registros (SQL thread)

5/47


"MySQL replication by default is asynchronous. The master
writes events to its binary log but does not know whether or
when a slave has retrieved and processed them. With
asynchronous replication, if the master crashes, transactions
that it has committed might not have been transmitted to any
slave. Consequently, failover from master to slave in this case
may result in failover to a server that is missing transactions
relative to the master"

http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html

6/47

MySQL - Replicación - funcionalidades

hasta 5.1 (2008):
1. log binario de sentencias, registros, o mixto
2. filtro de bases, tablas y transacciones
3. sentencias no determinísticas
4. disponible para Cluster

en 5.5 (2010):
1. semisincrónica
2. fsync mejorado en slave
3. recuperación de corrupción en relay log
4. heartbeat
5. filtro de eventos por servidor
en 5.6 (m3):
1. replication_event_checksum

7/47

Mysql - Replicación

Semisincrónica (5.5):

• parche original de google - 2007
• slaves confirman recepción de eventos al master
• commit se responde al cliente luego que un slave haya
confirmado recepción de evento
• implementado con plugins en master y slave
o rpl_semi_sync_master_enabled = 0/1;
o rpl_semi_sync_master_timeout = N;
 1000 = 1 segundo
o rpl_semi_sync_slave_enabled = 0/1;
• monitoreo
o SHOW STATUS LIKE 'Rpl_semi_sync%';

8/47


• ¿Cómo habilitar log binario?
log-bin # en my.cnf

• Si slaves van a tener habilitada réplica, habilitar que su
binlog incluya cambios aplicados del master
log-slave-updates # en my.cnf
• ¿Cuándo se genera un archivo nuevo?
– al reiniciar el servidor mysql
– al llegar al tamaño máximo (max_binlog_size)
– ejecutando FLUSH LOGS
• ¿Cuándo se borran los archivos de logbin?
– cuando se llega a EXPIRE_LOGS_DAYS
– ejecutando PURGUE MASTER LOGS

9/47


SET BINLOG_FORMAT=[row|statement|mixed|default];

statement
• almacena las sentencias SQL ejecutadas, DDL y DML.
• tamaño independiente del volumen de datos
• necesita que todas las tablas de la sentencia estén
replicadas.
• sentencias no determinísticas no son replicadas

row
• almacena datos modificados
• lockea solo datos necesarios
• recomendado cuando hay poco volumen de cambios

10/47


binlog filtrado en master:
• SET SQL_LOG_BIN=0
• binlog-do-db, binlog-ignore-db

filtrada aplicación en slave:
• replicate-do/ignore-db/table, replicate-do-table
• mysql proxy

NOTA: Binlog filtrado implica que no sirve para recuperación !

Configurar para consistencia
sync_binlog=1 # escribe binlog a disco después
de cada escritura
innodb_support_xa=1 # sincroniza binlog con InnoDB
datafiles (caídas innodb que genera rollback)

11/47


¿Replicación bi-direccional?
• No soportado.
o Esto quiere decir: slave no actualiza datos en master,
porque el flujo de datos es siempre en un sentido: del
master al slave.
• Se puede configurar master y slave en un mismo servidor, y
parece bi-direccional si ambos tienen configuración
simétrica, pero son dos configuraciones distintas.
• Problemas a considerar:
o autoincrementos
o restricciones de unicidad (UKs)
o cambios fuera de orden

12/47


Sentencias inseguras (unsafe) no son replicadas en formato
statement:
• no determinísticas

• aquellas que pueden retornar valor distinto en slave
sysdate(), user, UUID(), etc.

• otras sentencias no seguras:
update ... limit
insert delayed
load data infile # desde 5.1.50

• algunas no determinísticas se consideran seguras:
ej.: curtime(), last_insert_id()

13/47


Soporta cambios externos en la base de datos del slave:
• cambiar de engine en slaves
• master InnoDB y slave MyISAM
Servía hace algunos años cuando InnoDB no tenía buena
performance. Actualmente es discutible. Puede servir para algún caso
particular. Medirlo en el sistema!
●
Blackhole: filtro de datos

●
cambiar configuración de slaves buscando mejor performance

• cambiar índices

• cambiar configuración raid

14/47

MySQL - Replicación - 5.1
Replicación en cluster
• desde 5.1.6 master/slave. circular desde 5.1.18
• configuración de máxima disponibilidad

http://dev.mysql.com/doc/refman/5.5/en/mysql-cluster-replication.html 15/47


Contras:

• no hay automatización oficial de failover, se requiere
intervención manual o programación.

• escritura en slaves está limitada a un thread. Multi-thread en
5.6 (está en m6).

• es asincrónica y no transaccional, por lo que puede perder
datos. Mejorado en 5.5.2 (semisync) y 5.6 (crash recovery)

• slave necesita monitoreo: caídas, demoras, consistencia

16/47


Nativas
1. Replicación
2. Storage compartido
3. Cluster

De terceros
1. MMM
2. DRBD
3. Pacemaker
4. Galera
5. Tungsten

17/47

MySQL - Storage compartido

Activo/activo
• no soportado en InnoDB
• MyISAM:
o sobre cluster file system (OCFS2/GFS)
o parámetros necesarios:
 external-locking
 query-cache=0
 delay_key_write=off
Activo/pasivo
• Necesita software de terceros para heartbeat
• Failover:
o InnoDB aplica recovery
o MyISAM necesita que se valide que no hay tablas
corruptas: --myisam_recover como opción de arranque o
myisamchk antes de levantarlo.

18/47


Nativas
1. Replicación
3. Cluster

De terceros
1. MMM
2. DRBD
3. Pacemaker
4. Galera
5. Tungsten

19/47

MySQL - Cluster
Arquitectura shared nothing

http://dev.mysql.com/doc/mysql-cluster-excerpt/5.1/en/mysql-cluster-overview.html

20/47

MySQL - Cluster

A partir de mysql 5.5, cluster es una distribución independiente.
Actualmente está en producción 7.2

Nodo de datos - NDBD - Almacena datos e índices
●
Desde 7.2 soporta varios procesos (nodos) en mismo host
Nodo SQL - mysqld (versión 5.1)
• Maneja comunicación con cliente: recibe sentencias SQL y se
comunica con nodos de datos para ejecutarla
Nodo de Gestión - ndb_mgmd
• monitoreo, configuración y control del cluster
Datos se almacenan particionados y replicados entre NDBD
• fragmento activo (primario) y de failover (secundarios)
• parámetro NoOfReplicas es 2 por defecto
o valores mayores soportan caídas de más nodos
21/47

MySQL - Cluster

Caídas soportadas

nodo sql:
• clientes se desconectan y transacciones no commiteadas se
pierden

nodo datos:
• máximo NoOfReplicas-1
• en caso de split-brain, vive el grupo con mayoría de nodos, y
desempata nodo árbitro.

nodo gestión:
• no impacta el funcionamiento del cluster
• no se pueden agregar nuevos nodos hasta que vuelva

22/47

MySQL - Cluster

Varias operaciones online:
• backup
• software upgrade
• agregar nodos de datos
• system restart en modo "rolling"
o gestión, datos (de a uno, todos), sql (idem)

Balanceo de carga:
• Java Connector/J 5.0.6: jdbc:mysql:loadbalance://

Base ndbinfo con datos en vivo:
• nodos activos
• memoria usada (tabla memoryusage)
• varios contadores de actividad (tabla counters)

23/47

MySQL - Cluster

Recomendado para
• transacciones cortas y chicas
• sql con joins simples y búsquedas por PK
• alta disponibilidad

Casos de uso
• sistemas de tiempo real
• soporte a telefonía

Configuración - en práctico
• Usa un archivo de configuración global: config.ini
• local a cada nodo: my.cnf
o ubicación de nodos de gestión
• logs por nodo (ndb_#_out.log) y global (ndb_#_cluster.log)

24/47

MySQL - Cluster

Limitaciones
• mínimo tres equipos, máximo 255 (48 nodos de datos)
• lento en joins de mucho volumen y agregaciones
• no soporta índices fulltext ni foreing keys
• datos se almacenan en memoria (solo columnas indexadas
desde 5.5, antes todo), lo que limita el tamaño máximo de la
base a la capacidad de los servidores de datos.
• estimación de memoria RAM necesaria en cada nodo:
(SizeofDatabase x NumberOfReplicas x 1.1 ) /
NumberOfDataNodes

ndb_size.pl estima memoria necesaria en cluster a partir de
una instancia mysql común.
http://dev.mysql.com/doc/refman/5.5/en/mysql-cluster-programs-ndb-size-pl.html

25/47

MySQL - Cluster

MCM: MySQL Cluster Manager
• versión comercial: MySQL Cluster Carrier Grade Edition
• mcmd --bootstrap # instala cluster de 3 nodos configurado
• Redhat/OEL 5, SuSE EL10/11

26/47


Nativas
1. Replicación
3. Cluster

De terceros
1. MMM
2. DRBD
3. Pacemaker
4. Galera
5. Tungsten

27/47

Mysql - Multi Master Manager

http://mysql-mmm.org/
●
Scripts para monitoreo y failover de replicaciones
master/master con un solo nodo soportando escrituras

Scripts:
●
mmm_mond, mmm_agentd, mmm_control

Bug reportado 27/4/2011
• https://bugs.launchpad.net/mysql-mmm/+bug/771843
"moving slaves to the new master can cause inconsistency accross
databases"
• pasado a prioridad alta el 25/5, a resolver en v2.2

28/47


Nativas
1. Replicación
3. Cluster

De terceros
1. MMM
2. DRBD
3. Pacemaker
4. Galera
5. Tungsten

29/47

MySQL - DRBD

Distributed Replicated Block Device - http://www.drbd.org
• módulo en kernel linux que implementa replicación
sincrónica de bloques usando la red (raid-1)

30/47

MySQL - DRBD

Necesita software de gestión de cluster para automatizar:
• heartbeat / pacemaker

Ventajas
• alternativa barata a una caja de storage (SAN)
• datos quedan locales al servidor activo (performance)
• es más seguro que replicación nativa (consistencia)
• actualizaciones de hardware/software usando failover
contras
• soportado solo en linux
• agrega complejidad
• corrupción se propaga
• no permite replicar parte de la base

31/47

MySQL - DRBD

Activo/activo
• Sobre GFS/OCFS2
• Sólo con MyISAM

Con LVM
• se puede usar debajo y sobre DRBD
• snapshots sólo si LVM va debajo
• snapshots en slave permiten montar el filesystem para
maniobras read-only

Soporta mirroring sincrónico y asincrónico
• necesario para WAN, no recomendado para MySQL

32/47

Mysql - DRBD

Parámetros recomendados en MySQL:
• log-bin=nombre
por defecto es hostname y puede cambiar
• innodb_log_file_size
más chico permite recovery más rápido
• myisam_recover=force,backup
para chequeo automático de corrupción en failover
• innodb_support_xa=1
sincroniza binlog con innodb datafiles (caídas innodb que
genera rollback)
• sync_binlog=1
escribe binlog a disco después de cada escritura

33/47

MySQL - DRBD

Posibles fallas

master
1. caída del servidor
2. tranca sin que falle, no liberando recursos. Requiere fencing
del agente de cluster (heartbeat)
3. corte del enlace con secundario

secundario
1. caída del servidor
2. corrupción de datos por fallas en storage
3. corte del enlace con master

34/47


Nativas
1. Replicación
3. Cluster

De terceros
1. MMM
2. DRBD
3. Pacemaker
4. Galera
5. Tungsten

35/47

Pacemaker

Cluster resource manager - http://www.clusterlabs.org/
gpl (v2), no hay versión enterprise.
●
Apoyado por RedHat / Novell / LinBit.

Funcionalidades
• soporta infraestructura de OpenAIS y Heartbeat
• implementa STONITH para asegurar integridad de datos
• configuración redundante en CIB (cluster information base),
archivo XML
• usa cualquier recurso que pueda ser gestionado con scripts
• soporta varias configuraciones redundantes:
activo/pasivo, activo/activo, N+1, etc.
➢
Parte de Heartbeat hasta versión 2.1.3. Luego se independizó
➢
1.0 más testeado sobre Heartbeat que con Corosync

36/47

Pacemaker Stack
http://www.clusterlabs.org/wiki/Architecture#Supported_Cluster_Stacks

37/47

Pacemaker Internals
http://www.clusterlabs.org/wiki/Architecture#Supported_Cluster_Stacks

38/47

Pacemaker
con MySQL
●
gran comunidad de usuarios
●
percona-prm: Mysql Replication Manager (alpha)

Pasos para comenzar a utilizarlo:

●
Configurar Heartbeat
/etc/ha.d/ha.cf

●
Configurar recursos
Muchos parámetros, estudiar bien opciones
Stonith para producción

●
Probar escenarios !

39/47

Pacemaker

Recurso:
●
clase: OCF/lsb/legacy-heartbeat/stonith
●
parámetros
●
operaciones de monitoreo
●
scores: usado en toma de decisiones
- = no usar
+ = usar
INFINITY = constante

●
lsb: script de inicio cumpliendo Linux Standard Base

●
OCF: Open Cluster Framework, extensión de LSB

40/47

Pacemaker
●
Ejemplo de configuración para DRBD:

$> crm configure edit
primitive drbd_disk ocf:linbit:drbd
params drbd_resource="mysql"
op monitor interval="15s"
primitive fs_drbd ocf:heartbeat:Filesystem
params device="/dev/drbd0" directory="/varios/01" fstype="ext3"
ms ms_drbd drbd_disk
meta master-max="1" master-node-max="1" clone-max="2"
clone-node-max="1" notify="true"
colocation mnt_on_master inf: fs_drbd ms_drbd:Master
order mount_after_drbd inf: ms_drbd:promote fs_drbd:start

41/47


Nativas
1. Replicación
3. Cluster

De terceros
1. MMM
2. DRBD
3. Pacemaker
4. Galera
5. Tungsten

42/47

MySQL - Galera

Replicación sincrónica
http://codership.com/products/galera_replication

43/47

MySQL - Galera

Características
• Réplica en tiempo de commit
• Sincrónica y multi-master
• gestiona variables de autoincremento
• Lleva ID de transacciones para garantizar consistencia
• controla datos a replicar al recibirlos y antes de aplicarlos
(certificación)
• Implementación genérica. Primera versión en InnoDB.
• Parche para MySQL
• Configurable mediante variables en my.cnf
'wsrep%';
• Publica variables de estado
o show status like 'wsrep%';
• control de flujo con triggers (exceso de carga)

44/47


Nativas
1. Replicación
3. Cluster

De terceros
1. MMM
2. DRBD
3. Pacemaker
4. Galera
5. Tungsten

45/47

MySQL - Tungsten Replicator

Opensource, GPL V2, y versión enterprise
http://www.continuent.org

Funcionalidades
• replicación en paralelo, multi-master y heterogena (aplica a
PostgreSQL, MySQL y Oracle).
• implementa ID de transacciones global
• múltiples servicios de replicación por proceso (N-N)

Buena documentación:
http://code.google.com/p/tungsten-replicator/wiki/TungstenReplicatorCookbook
http://code.google.com/p/tungsten-replicator/wiki/Troubleshooting

46/47

MySQL - Tungsten Replicator

Conector:
• intermedia entre aplicación y BD
• implementación nativa MySQL y PostgreSQL
• incluye módulo router que se comunica con la BD, e
implementa HA

Replicator: captura cambios y propaga a otros replicators,
usando protocolo propio TLH.

Manager: monitorea estado de componente, mediante módulos
monitores: replicator, database y cluster.

47/47

Alternativas de alta disponiblidad en MySQL - MySQL Meetup - Montevideo - Marzo 2012

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

Similar a Alternativas de alta disponiblidad en MySQL - MySQL Meetup - Montevideo - Marzo 2012 (20)

Más de Nelson Calero (20)

Último (20)

Alternativas de alta disponiblidad en MySQL - MySQL Meetup - Montevideo - Marzo 2012