Archive of November 2010
Backup online y consistente en MySQL Cluster
En MySQL Cluster existen diferentes formas de hacer backup y debido a su arquitectura distribuida hay unas más recomendables que otras. Aquí vamos a ver la nativa, usando el cliente nbd_mgm. Desde esta herramienta de control podremos lanzar ordenes de backup que ejecutará cada nodo de almacenamiento, sacando un snapshot consistente de los datos y sin necesidad de parar el sistema.
Un backup en MySQL Cluster consiste en tres ficheros:
- Metadatos
BACKUP-backup_id.node_id.ctl
Es un fichero donde se guardan las definiciones de las tablas.
- Datos de las tablas
BACKUP-backup_id-0.node_id.data
Cada nodo guardará en este fichero los fragmentos de las tablas que gestiona.
- Log de transacciones
BACKUP-backup_id.node_id.log
Es el log de las transacciones con commit de las que se harán backup.
Siendo backup_id el identificador del backup y node_id el identificador del nodo. Cada nodo guardará los ficheros en su disco local, pero es recomendable que todos escriban al mismo destino, posiblemente un NAS, ya que a la hora de recuperar tendremos que tener accesibles todos los ficheros de cada nodo desde una única ubicación.
Para lanzar el backup nos conectamos con la utilidad ndb_mgm al management node y ejecutamos:
ndb_mgm> START BACKUP
Por defecto la herramienta se quedará parada (no podremos ejecutar más comandos) hasta que el backup se complete (WAIT COMPLETED). Pero podremos cambiar este comportamiento añadiendo el parámetro NOWAIT o WAIT STARTED.
Para parar un backup:
ndb_mgm> ABORT BACKUP id
Para definir donde queremos que vayan nuestros backups debemos hacer global para todos los nodos el parámetro BackupDataDir.
Como hemos visto, hacer un backup en caliente es sencillo y no tienen ningún tipo de downtime. Esto no es así para el proceso de restauración, que no debería hacerse online. Como indica la documentación de MySQL, el engine NDB no soporta repeatable reads. Por lo tanto durante el proceso de restauración las transacciones en ejecución reciben lecturas no repetidas (nonrepeatable) y por lo tanto tendremos datos incosistentes.
Se recomienda por ello hacer la restauración con el Cluster parado para evitar esta serie de problemas. Para ello lanzamos el Cluster en Single Mode de forma que un único API node (ndb_restore) tenga acceso a los datos.
Para restaurar un backup haremos uso de la utilidad ndb_restore:
ndb_restore [-c connectstring] -n node_id [-m] -b backup_id -r --backup_path=/path/to/backup/files
Donde:
- connectstring: dirección ip y puerto del management node.
- node_id: número de nodo a restaurar
- backup_id: id de backup a restaurar
- -m: si deseamos recrear las tablas a partir de los metadatos
- backup_path: ruta donde se encuentran los archivos con nuestros backups
Habrá que ejecutarlo una vez por cada nodo. Una vez restaurado podemos salir del Single Mode y permitir así de nuevo el acceso a los lusers.