LinuxParty

Y como dice el refrán, “uno propone y Dios dispone”. Esto va a epíteto de la manera en que terminan las cosas en lo que a desarrollo de software se refiere. Un día propones un sistema, Open Source por supuesto, y rápidamente la data prolifera. Y lo que antes pesaba unos pocos megas hoy en día ya está pasando los dos gigas. Un día oí a alguien decir que esa era la tónica que tomaban los sistemas que emplean MySQL como backend de datos. El peor escenario, donde tiene una base de datos de más de 2 GBytes, y tienes que cargar el respaldo tomará bastante tiempo en tener la base de datos operativa. No solo toma tiempo el cargar el respaldo, sino que además, hasta generar el respaldo puede tomar bastante tiempo.

Hurgué un poco en Internet, en la documentación que acompaña las distribuciones de MySQL y llegué a algo que no tienen nada que envidiarle a motores como Oracle o MS SQL.

Hay hartas maneras de respaldar una base de datos en MySQL, pero cuando la data es muy grande, hay solo una. En este artículo espero dejarles un manual de cortapalos para que piensen en grande cuando levanten su próximo servidor de MySQL, ya que respaldar una base de datos MySQL en hot es una cualidad que va de la mano con Linux. Dónde más pensaban levantar MySQL?.

1.1. Problemas al Respaldar con MySQLDump.

Si bien MySQL trae un utilitario para hacer respaldos de las base de datos llamado mysqldump, esta aplicación lo único que hace es generar un script en SQL de la creación y poblamiento de tablas e índices.

Esta aplicación tiene sentido cuando la data es muy pequeña, tomando como referencia a 1 GB. Pero a medida que la data crece, se tienen  muchos índices y se requiere alta disponibilidad del sistema verán que mysqldump no es lo más indicado.

1.1.1. Problemas con el respaldo de MySQLDump.

Como se explicó anteriormente, lo que nos entrega mysqldump es un script de SQL donde viene en duro la creación de todos los objetos de la base de datos y la carga de la data vía el comando INSERT.

Se han puesto a pensar que pasa cuando dentro de la data tiene columnas del tipo BLOB y TEXT?

En general, si la base de datos es grande, mayor a 1GB, notarán el overhead de tener que recrear los objetos y poblarlos.

1.1.2. Problemas Regenerando Índices.

Como se explicó anteriormente, mysqldump solo nos entrega un script que detalla la creación de los objetos de la base de datos, y su poblamiento.

Respecto a los índices esto es un poco más complicado. Imaginen que tienen una tabla con 15 millones de filas, la cual tiene 3 índices compuestos con al menos 2 campos. En la visa real viví una situación donde la generación de los índices tomó cerca de 2 horas. Si bien la carga de la data tomo casi 45 minutos, solo la compilación de los índices le dio un downtime de 3 horas. Para sistemas críticos esto es inaceptable. MySQLDump no sirve para respaldar a medida que la data crece.

1.1.3. Respaldo o Alta Disponibilidad.

Ya se han mencionado los problemas claves de mysqldump a medida que la data crece, pero se han puesto a pensar que es lo que pasa dentro de la base de datos cuando se respalda con mysqldump?

Bueno, internamente, en MySQL se producen una serie de bloqueos en las tablas que se están respaldando que detiene cualquier transacción que quiera tener acceso a los objetos. En resumen, la disponibilidad de la base de datos cae estrepitosamente mientas dura el dump.

1.2. Problemas Copiando Archivos.

Con todo lo anterior uno se verá tentado a copiar los archivos con el comando CP o con TAR, pero hay unas sutilezas que hay que tener en cuenta cuando se está tratando con bases de datos grandes, sobre 1 GB.

1.2.1. Caché del Filesystem.

Muchas veces, el sistema operativo y en especial Linux, para mejorar el desempeño de Entrada/Salida hacia el disco se emplean estructuras que cachean tanto bloque como i-Nodos. Estas estructuras están en memoria RAM y median un engaño aceleran todas las escrituras y lecturas.

Si estamos pensando en copiar vilmente el directorio donde reside la base de datos de MySQL nos encontraremos con datos fantasmas dentro del respaldo. Esto ocurre porque mucha de la data está en caché de archivo del MySQL y del Filesystem. Por eso, si estamos en presencia de una base de datos grande, lo mejor será descartar esta alternativa.

Cabe mencionar que en jerga de DBA’s es mejor perder un par de horas del día que la consistencia de la base de datos. Eso no tiene precio, como dicen los spots de Visa.

1.3. Tomando un Snapshoot de un FileSystem.

Ya que para respaldar una base de datos grande no nos sirve ni mysqldump ni copiarla con cp, se preguntarán entonces cómo?.

Bueno, la solución que hallé va de la mano con Linux, e implica el haber previamente montado la partición donde estará la data de MySQL con LVM y haber dejado como mínimo un 10% de la base de datos libre.

1.3.1. Qué es LVM.

Hay harta documentación de LVM en Internet, pero a modo de resumen:

1) LVM es un sistema de manejo dinámico del storage.

2) Es posible hacer crecer dinámicamente particiones con LVM sin necesidad de contar con storage que sirva de pivote.

3) Es nativo para Linux y los filesystem también pueden crecer dinámicamente.

4) LVM tiene la capacidad de hacer snapshot de un volumen. Esto lo explicaremos en el próximo punto.

1.3.2. Qué es un Snapshot de LVM.

Un Snapshot de LVM es un mecanismo mediante es cual es posible respaldar en hot una partición, congelándola durante el proceso de respaldo para que la data en ella no cambie.

Snapshot de LVM para dejar inmutable la partición a respaldar requiere de una área especial llamada Backingstore donde irá almacenando los bloques e inodos que cambian de la partición. Cuando el snapshot se acabe, toda esta data pasará a la partición. Esta es la característica fundamental que hace a los Snapshots de LVM en Linux aptos para respaldar en hot toda una base de datos.

1.3.3. Uniendo todo.

En fin, podríamos resumir lo siguiente, referente a respaldar una base de datos gigante de MySQL en Linux.

1) Haber creado el Filesystem de la partición donde estará alojada la data bajo Linux LVM.

2) Haber reservado espacio dentro del volumen lógico de la partición con LVM al menos un 10% para montar un snapshot.

3) Para respaldar, solo bastaría con montar un snapshot en el volúmen lógico y luego copiar la data con TAR u otro archivador.

En la vida real, con este mecanismo, he respaldado base de datos de Zimbra de más de 600 GBytes sin ningún problema. Doy fe que resulta.

1.4. Un Script de Ejemplo

Ahora les anexo un script prototipo que monta el snapshot.

Las variables hablan por sí solas.

1) /dev/VolGroupMYSQL es el nombre de la particion donde está la

data de MySQL.

2) /backup es donde monto el snapshot para copiarlo.

3) El nombre del snapshot es SnapshotMySQL y le doy como tamaño 1 GB.

---

#!/bin/bash

 

[ "x$1" = "x--debug" ] && set -x && shift

xBase=/backup

xBaseVolume=/dev/VolGroupMYSQL

xVolume=$xBaseVolume/LogVol00

xNameSnapshot=SnapshotMySQL

xVolumeSnapshot=$xBaseVolume/$xNameSnapshot

xSizeSnapShot=1g

xMPSnapshot=$xBase/snapshot

xMySQLDir=$xBase/mysql

#############################################################################

function Die () {

echo $1

# Por aca debe ir el codigo para el envio de un mail

exit 1

}

export PATH=”$PATH:/usr/sbin”

#############################################################################

[ -d $xBase ] || mkdir $xBase || Die “No puedo crear [$xBase]”

lvcreate –size $xSizeSnapShot –snapshot  –name $xNameSnapshot $xVolume || Die “No pude crear el snapshot”

[ -d $xMPSnapshot ] || mkdir $xMPSnapshot || Die “No pude crear el punto de montage del snapshot”

mount $xVolumeSnapshot $xMPSnapshot || Die “No puedo montar el snapshot”

[ -d $xMySQLDir ] && /bin/rm –force -R  $xMySQLDir

[ -d $xMySQLDir ] || mkdir $xMySQLDir

/bin/cp -a  $xMPSnapshot/* $xMySQLDir

umount $xVolumeSnapshot || Die “No pude desmontar el snapshot”

lvremove -f $xVolumeSnapshot || Die “No pude eliminar el snapshot”

---

Via: eDreams.cl