MariaDB / Backups fisicos

Bienvenidos sean a este post, hoy hablaremos sobre los backups fisicos.

Cuando nos referimos a un backup fisico estamos hablando de una copia de todos los archivos en los cuales mariadb almacena las definiciones de base de datos, archivos de configuracion y logs, dado que esta informacion es almacenada de una forma compacta por lo tanto este es usualmente la forma mas conveniente de backup, otra particularidad es que este backup solo incluye los archivos de configuracion y logs, aunque mientras hagamos este backup se debe utilizar un bloqueo para que el servidor no use ninguno de los archivos, como alternativa podemos detener al servidor, un backup completo almacena los siguientes grupos de archivos:

• Archivos de tablas
• Archivos de triggers
• Archivos de logs
• Archivos de configuraciones

Pasemos a hablar sobre cada uno de estos archivos, los archivos de tablas son almacenadas en el directorio data, si bien el motor de almacenamiento, y en algunas ocasiones su configuracion, determina cuales archivos contienen los datos de la tabla e indices, dentro del directorio data tendremos un directorio por cada base de datos, sera representada con el nombre de la misma, dentro de este directorio estaran los archivos de las tablas que tambien poseen el mismo nombre que la tabla y estos tienen una extension que dependera del tipo de tabla, si necesitamos saber la ubicacion del directorio data podemos usar a la variable @@datadir:

MariaDB [(none)]> select @@datadir;
+-----------------+
| @@datadir       |
+-----------------+
| /var/lib/mysql/ |
+-----------------+
1 row in set (0.002 sec)

MariaDB [(none)]>

Esto es lo referido a lo mas basico de una base de datos pero tambien tenemos los espacio de tablas de InnoDB, estos pueden estar ubicados en un lugar distinto de la base pero podemos averiguar este dato por medio de la variable @@innodb_data_home_dir, aunque otros espacios de tablas son ubicados en un path especificado en la variable @@innodb_data_file_path, sin embargo algunos motores de almacenamiento permiten utilizar una ubicacion diferente para los archivos de tablas, esto podemos definirlo utilizando las opciones de tabla DATA_DIRECTORY e INDEX_DIRECTORY, si deseamos verlo podemos hacerlo por medio de SHOW CREATE TABLE.

El servidor crea un archivo de extension .frm que contendra las definiciones de la tabla, si bien algunos motores pueden funcionar sin este archivo lo recomendable es que siempre este sin importar el motor que se este usando, en este post explicamos que InnoDB tiene un modo de archivo por tabla que afecta la creacion de los archivos de tablas, como dijimos un espacio de tabla de sistema siempre existe y es almacenado en los archivos cuyos nombres comienzan con ibdata, si esta habilitado generara archivos con la extension .ibd para los espacios de tablas pero si esta desactivado utilizara los del sistema, veamos cuales extensiones utiliza cada motor para las tablas e indices:

Motor	Tablas	Indices
Aria	.MAD	.MAI
MyIsam	.MYD	MYI
ARCHIVE	.ARZ
CONNECT	Definida por el usuario	.dnx
CSV	.CSV

El motor de almacenamiento MERGE no crea archivos de tablas o indices pero si utiliza un archivo MRG que contiene las tablas MyIsam subyacentes, Aria tambien usa logs los cuales nombra como aria_log y las extensiones son numeros progresivos y tambien es necesario aria_log_control.

Si bien ya vimos como almacenar las tablas y los archivos necesarios para obtener una recuperacion idonea pero tambien hay otros archivos que deberiamos salvar como son las rutinas, triggers y eventos que son llamadas colectivamente programas almacenados, estos estan pensados para implementar la logica de la base de datos en simples scripts de SQL, estos objetos no cambian a menudo (tal como las estructuras de las tablas) pero como dijimos antes un backup de estos programas aun son necesarios para correcta restauracion del servidor, si bien su definicion es almacenada en tablas del sistema contenidas en la base mysql, un backup de esta base contendra todos los programas almacenados existentes, sin embargo los triggers generan los siguientes archivos dentro del directorio data:

• nombre_trigger.TRG
• nombre_trigger.TRN

Para un correcto almacenamiento debemos incluir estos archivos, pasemos a ver los archivos logs.

Los paths y nombre de archivos de los logs del servidor son definidos en algunas variables del servidor, veamos las variables que podemos usar para obtener los datos del path de estos:

Log	Variable del servidor
Log de Error	@@log_error
Log de query general	@@general_log
Log de query lento	@@slow_query_log
Log binario	@@log_bin

Manteniendo los archivos de logs en el directorio data deberia simplificar el procedimiento de backup, pasemos a hablar sobre los archivos de configuracion.

Si existe solo una version de mariadb en el equipo solo se ejecuta una instancia, siempre sera ejecutado con el mismo usuario y se usara un solo archivo de configuracion, por lo general se encuentra dentro del directorio de instalacion de mariadb, se llama my.cnf (en windows puede llamarse my.ini), en cambio si existen varias versiones de mariadb en el mismo equipo, o si puede ejecutarse mas de una instancia al mismo tiempo, con esto el usuario puede tomar ventaja de la configuracion modular de mariadb con algunos archivos de configuracion que contengan las especificaciones generales y archivos mas especificos que anulan ciertas especificaciones para una o mas instancias, veamos algunos paths donde pueden estar ubicados en Linux o Unix:

• /etc
• /etc/mysql
• El valor en la variable SYSCONFDIR
• El valor en la variable $MYSQL_HOME
• El valor indicado con la opcion –defaults-extra-file
• ~/ (El home del usuario)

Ahora pasemos a ver lo mismo para Windows:

• El path %PROGRAMDATA%\MariaDB\MariaDB Server 10.0
• El valor de la variable %WINDIR%
• C:\
• El directorio de instalacion
• El valor indicado con la opcion –defaults-extra-file

Otros tema que tenemos son los backups fisicos calientes, si bien un backup fisico en general se hace en frio mediante la detencion del servidor pero en algunas circunstancias no podemos hacer esto, y en estos casos debemos asegurarnos que el servidor no intente modificar los datos hasta que se finalice el proceso de backup, para poder realizar esto debemos descargar las tablas al disco y despues bloquear las tablas, para ello podemos usar los siguientes comandos:

FLUSH TABLES <lista_tablas> FOR EXPORT

FLUSH TABLES [lista_tablas] WITH READ LOCK

En el primer caso la lista de tablas es mandatoria, en cambio para el segundo caso es opcional dado que sino informamos ninguna bloqueara todas las tablas, entonces veamos como deberiamos trabajar con estos comandos:

• Ingresamos con el cliente
• Ejecutamos alguno de los dos comandos anteriores y dejamos la sesion abierta
• Desde otro cliente o programa comenzamos la copia de los datos
• Una vez terminado desde el primer cliente liberamos el bloqueo con UNLOCK TABLES

La principal diferencia entre estos dos comandos radica que en FOR EXPORT es mas segura y confiable pero no existe para versiones mas vieja de la 10.0 e inclusive no es soportado por algunos motores, en cambio READ LOCK es ejecutado por el servidor por lo tanto funcionara con cualquier motor aunque es menos confiable que el anterior, aunque si bien no existen muchas diferencias entre ambos con respecto a los distintos motores el mas recomendado es FOR EXPORT.

Algunos sistemas de archivos o administradores de volumnes soportan instantaneas (snapshots), el archivo de sistemas Veritas lo soporta, otros como XFS pueden crear estas instantaneas via LVM, esta opcion es muy interesante dado que nos permite crear backups fisicos de una manera muy rapida, si bien no es necesario detener el servidor tenemos a FLUSH TABLES … WITH READ LOCK para bloquearlo, veamos como seria el procedimiento:

• Ingresamos con el cliente
• Ejecutamos el comando FLUSH mencionado
• Desde una terminal ejecutamos este comando: mount vxfs snapshot
• Una vez terminado desde el cliente ejecutamos a UNLOCK TABLES

Como pueden ver es muy similar a lo visto en el caso anterior, tambien disponemos de la herramienta mylvmbackup la cual viene incluida en la mayoria de las distribuciones de Linux y nos permite automatizar este procedimiento.

Otro comando de linux que podemos utilizar es rsync el cual nos permitira hacer copias de archivos en una forma incremental, cuando este es invocado en un archivo que nunca ha sido copiado procede a copiarlo, pero cuando es llamado en ese archivo nuevamente chequea si el archivo ha sido modificado desde la ultima vez que se copio, si se modifico rsync copia la parte modificada del archivo lo cual hace que estas copias de backup se hagan mas rapido sobre una red, en cambio cuando se usa en un directorio rsync ejecuta un chequeo para cada archivo individual dentro del directorio, este comando incluso puede borrar un archivo del directorio de destino si este fue eliminado del directorio de origen, aunque esto para los backups no es una buena idea porque si un archivo esta perdido quizas debamos restaurarlo, con esto podemos decir que rsync no es bueno para bases de datos OLTP, sin embargo las bases de datos OLAP contienen muchas tablas grandes que no son actualizadas a menudo, ahora cuando ejecutamos un backup de estas bases de datos queremos salvar tiempo copiando las tablas que han sido modificadas, y si despues queremos restaurar una tabla solamente debemos usar el backup mas reciente para esa tabla.

En resumen, hoy hemos visto como es el backup fisico, todas las posibilidades que tenemos, algunas caracteristicas, los distintos archivos que debemos tener en cuenta para trabajar con los mismos, algunos pasos como buen practica para trabajar de la mejor forma posible, espero les haya sido de utilidad sigueme en tumblr, Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.