Copia de seguridad de bases de datos MariaDB consistentes

El objetivo es hacer copias de seguridad de un servidor de bases de datos MariaDB de manera que sean consistentes y minimizando el efecto de hacer los backups sobre el funcionamiento normal del servidor.

Como solución inicial, vamos a utilizar mysqldump que vuelca la estructura y datos de los esquemas en sentencias sql. Como ventaja tiene que es muy fácil de usar y que se pueden editar las setencias resultantes, por ejemplo, antes de exportarlas a otra base de datos. Como desventaja es que el recrear una base de datos de esta forma lleva mucho tiempo.

mysqldump se conecta como cliente al servidor para hacer el volcado de los datos. Para evitar problemas de seguridad, vamos a crear un nuevo usuario con los privilegios mínimos para que mysqldump pueda funcionar. Dependiendo del tipo de motor, necesitaremos unos privilegios u otros. Por ejemplo, estos son los privilegios que se necesitan para los motoros InnoDB y MyISAM:

InnoDB

CREATE USER ‘backup’@’localhost’ IDENTIFIED BY ‘secret’; GRANT SELECT, SHOW VIEW, RELOAD, REPLICATION CLIENT, EVENT, TRIGGER ON *.* TO ‘backup’@’localhost’;

MyISAM

GRANT LOCK TABLES ON *.* TO 'backup'@'localhost';


 

Monitorizar cambios en Galera Cluster

Para chequear el estado de un cluster Galera se puede inspeccionar cada uno de los nodos que lo componen y comprobar que se hayan en funcionamiento y sincronizados. Pero hay una alternativa que el propio Galera implementa. Está muy bien documentado en los siguientes enlaces:

  • http://galeracluster.com/documentation-webpages/monitoringthecluster.html
  • http://galeracluster.com/documentation-webpages/notificationcmd.html

Como se explica ahí, Galera permite enviar notificaciones cuando detecta algún cambio en el estado del cluster, a través de la llamada a un script o programa con los argumentos que ahí se comentan (--status, --uuid, --members, --index). El script que viene como ejemplo puede ser suficiente para la mayoría de los casos. Cada vez que Galera detecta un cambio, invoca al script pasándole los respectivos argumentos. Éste crea un schema dentro de la propia base de datos, desactivando para ello la replicación en esta sesión, de modo que cada uno de los nodos tienen información propia en los registros que crean. Al script por defecto yo simplemente he añadido una línea para que, además de actualizar las tablas con los cambios, envíe un mail al administrador para que pueda actuar si es necesario.