La función de gestión centralizada de copias de seguridad de ClusterControl admite mysqldump estándar, copias de seguridad Percona Xtrabackup y Mariabackup proporcionadas por MariaDB. Creemos que los argumentos de la línea de comandos elegidos para los métodos respectivos son óptimos para la mayoría de las cargas de trabajo de la base de datos y cumplen con las mejores prácticas de respaldo de MySQL. Nos basamos en todos los comentarios que hemos recibido a lo largo de los años, cuando trabajamos con administradores de bases de datos y administradores de sistemas. Sin embargo, la configuración puede no ser suficiente en algunas circunstancias. Es posible que aún desee personalizarlo para que se adapte a su entorno, utilizando el método de copia de seguridad respectivo. En esta publicación, le mostraremos cómo hacerlo.
mysqldump
Para realizar una copia de seguridad desde la interfaz de usuario de ClusterControl, vaya a ClusterControl -> Seleccionar clúster -> sección Copia de seguridad. Aquí puede ver las copias de seguridad generadas y puede crear o programar una nueva.
Desde la interfaz de usuario de ClusterControl, tenemos algunas opciones diferentes para realizar la copia de seguridad. Podemos crear un archivo de volcado para cada base de datos, habilitar la copia de seguridad parcial, almacenar la copia de seguridad en el nodo o en el servidor ClusterControl; podemos especificar el directorio y el subdirectorio de la copia de seguridad, o podemos archivar automáticamente la copia de seguridad en la nube (AWS, Google Cloud o Azure) mediante la función de carga en la nube.
Además, podemos usar la compresión, cifrar nuestra copia de seguridad y especificar el período de retención.
Por defecto, ClusterControl nos permite elegir entre 4 tipos de volcado diferentes para realizar la copia de seguridad:
- Esquema y datos:esquema y datos de la base de datos
- Solo esquema:esquema de base de datos
- Solo datos:datos de la base de datos
- Solo MySQL Db:base de datos del sistema MySQL
Digamos que tenemos 5 bases de datos y elegimos hacer una copia de seguridad de todas ellas. Esto es lo que ejecutará ClusterControl al realizar la copia de seguridad mediante el método mysqldump (los comandos se recortan con una barra invertida para facilitar la lectura):
- Esquema y datos
$ /usr/bin/mysqldump \ --defaults-file=/etc/my.cnf \ --flush-privileges \ --hex-blob \ --opt \ --single-transaction \ --skip-lock-tables \ --triggers \ --routines \ --events \ --set-gtid-purged=OFF \ --databases mysql proxydemo sakila sbtest mydb \ --ignore-table='mysql.innodb_index_stats' \ --ignore-table='mysql.innodb_table_stats' \ |gzip -6 -c > /root/backups/BACKUP-1/mysqldump_2018-11-06_203010_schemaanddata.sql.gz'. - Solo esquema
$ /usr/bin/mysqldump \ --defaults-file=/etc/my.cnf \ --flush-privileges \ --hex-blob \ --opt \ --no-data \ --add-drop-table \ --triggers \ --routines \ --events \ --single-transaction \ --skip-comments \ --skip-lock-tables \ --set-gtid-purged=OFF \ --databases mysql proxydemo sakila sbtest mydb \ |gzip -6 -c > /root/backups/BACKUP-2/mysqldump_2018-11-06_210040_schemaonly.sql.gz'. - Solo datos
$ /usr/bin/mysqldump \ --defaults-file=/etc/my.cnf \ --flush-privileges \ --hex-blob \ --opt \ --no-create-info \ --single-transaction \ --skip-comments \ --skip-lock-tables \ --skip-triggers \ --skip-add-locks \ --set-gtid-purged=OFF \ --databases mysql proxydemo sakila sbtest mydb \ --ignore-table='mysql.innodb_index_stats' \ --ignore-table='mysql.innodb_table_stats' \ |gzip -6 -c > /root/backups/BACKUP-3/mysqldump_2018-11-06_210445_dataonly.sql.gz'. - Solo base de datos MySQL
$ /usr/bin/mysqldump \ --defaults-file=/etc/my.cnf \ --flush-privileges \ --hex-blob \ --opt \ --single-transaction \ --skip-comments \ --skip-lock-tables \ --skip-add-locks \ --set-gtid-purged=OFF mysql \ |gzip -6 -c > /root/backups/BACKUP-5/mysqldump_2018-11-06_211135_mysqldbonly.sql.gz'.
Si nuestro nodo MySQL está generando registros binarios, tendremos el parámetro master-data=2 incluido en los comandos anteriores y 1 tipo de volcado adicional disponible:
- Completo compatible con PITR
$ /usr/bin/mysqldump \ --defaults-file=/etc/my.cnf \ --flush-privileges \ --hex-blob \ --opt \ --master-data=1 \ --single-transaction \ --skip-lock-tables \ --skip-lock-tables \ --triggers \ --routines \ --events \ --all-databases \ |gzip -6 -c > /root/backups/BACKUP-6/mysqldump_2018-11-06_211451_complete.sql.gz'.
De las líneas de comando anteriores, podemos ver que en cada comando mysqldump, ClusterControl incluye el archivo de configuración de MySQL en su argumento --defaults-file. Al tener esto, el proceso mysqldump puede leer el contenido de la directiva mysqldump. De forma predeterminada, ClusterControl configura las credenciales de usuario de respaldo en un archivo separado en /etc/my.cnf.d/secrets-backup.cnf y max_allowed_packet en my.cnf, similar a lo siguiente:
$ mi.cnf
[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8$ secretos-backup.cnf
[mysqldump]
user=backupuser
password=ETgAG5VnpvuyXniELa ventaja de esto es que podemos incluir algunas opciones adicionales para mysqldump. Desafortunadamente, el argumento --defaults-file solo se puede especificar como el argumento principal. Preste atención a que los últimos argumentos de la línea de comando tienen prioridad sobre lo que se configuró dentro de my.cnf bajo la directiva [mysqldump] según el orden en que aparecen. Por ejemplo, si agregamos skip-comments=0 dentro de my.cnf, mientras que al final del comando mysqldump hay un --skip-comments (o --skip-comments=1), el primero será ignorado y se utilizará este último.
Sin embargo, todavía podemos usarlo como parte de nuestra personalización de respaldo usando otras opciones de respaldo de mysqldump. Por ejemplo, podemos excluir tablas de las que no queremos hacer una copia de seguridad utilizando el parámetro ignore-table (con el formato "database.table"). Agregue las siguientes líneas en el archivo de configuración de MySQL:
[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8
ignore-table=sbtest.sbtest9
ignore-table=sbtest.sbtest10
ignore-table=sbtest.sbtest1Una vez configurado, podemos activar un nuevo trabajo de mysqldump desde ClusterControl y mysqldump omitirá esas tablas. No es necesario reiniciar MySQL.
Puede consultar la documentación de mysqldump para obtener más información.
Percona Xtrabackup
ClusterControl ejecuta el Xtrabackup dependiendo de las opciones que elija. Puede ser completo o incremental y puede elegir varias variables desde la interfaz de usuario de ClusterControl. Considere lo siguiente:
En este paso puede elegir algunas variables que mencionamos anteriormente en la sección mysqldump, y luego:
Podemos especificar algunos detalles como el nodo de desincronización durante la copia de seguridad, Xtrabackup Parallel Copy Threads y más.
Según las opciones anteriores, el comando completo de Xtrabackup sería:
$ ulimit -n 256000 && LC_ALL=C /usr/bin/innobackupex --defaults-file=/etc/mysql/my.cnf --galera-info --parallel 1 --stream=xbstream --no-timestamp . | gzip -6 - | socat - TCP4:192.168.100.110:9999 ) 2>&1.El primer comando “ulimit -n 256000” es para asegurarse de que Percona Xtrabackup tenga privilegios suficientes para acceder a una gran cantidad de descriptores de archivos (en caso de que las bases de datos contengan muchas tablas). Tome nota de --defaults-file=/etc/mysql/my.cnf, que es similar a mysqldump, donde innobackupex lee el contenido de la configuración de MySQL en las siguientes directivas y variables:
[mysqld]
datadir=[physical path to MySQL data directory]
tmpdir=[path to temporary directory]
[xtrabackup]
user=backupuser
password=[random password]Si desea personalizar las opciones de respaldo para Percona Xtrabackup, puede agregarlas directamente bajo la directiva [xtrabackup]. Por ejemplo, digamos que queremos que Xtrabackup imprima la posición del registro binario cuando se realiza la copia de seguridad, podemos agregar algo como esto:
[xtrabackup]
user=backupuser
password=[random password]
slave-info=1La activación del trabajo de xtrabackup incluirá un archivo llamado archivo xtrabackup_slave_info. No es necesario reiniciar MySQL.
Puede consultar la documentación de Percona para obtener más información sobre su funcionamiento.
Copia de seguridad de María
Mariabackup es una bifurcación de Percona XtraBackup con soporte adicional para la compresión de MariaDB 10.1 y el cifrado de datos en reposo. Se incluye con MariaDB 10.1.23 y versiones posteriores.
El método de copia de seguridad puede ser completo o incremental y puede seleccionar las mismas variables que tiene para Percona XtraBackup, como Compresión, Xtrabackup Parallel Copy Threads o Cifrado.
El comando Mariabackup sería:
$ /usr/bin/mariabackup \
--defaults-file=/etc/my.cnf \
--backup \
--galera-info \
--parallel 1 \
--stream=xbstream \
--no-timestamp \
| gzip -6 - > /root/backups/BACKUP-8/backup-full-2018-11-07_015807.xbstream.gz ) 2>&1.Mariabackup se basa en Percona XtraBackup, por lo que utiliza la misma información que Percona para realizar la copia de seguridad. De forma predeterminada, ClusterControl agrega las siguientes líneas en el archivo my.cnf:
[xtrabackup]
databases-exclude=lost+found
# ssl_mode = DISABLED
ssl = 0Y las credenciales en el archivo secrets-backup.cnf:
[xtrabackup]
user=backupuser
password=[random password]Si desea agregar alguna variable, puede agregarla en la sección [xtrabackup].
Puede consultar la documentación de MariaDB para obtener más información sobre qué parámetro agregar.
En cada caso, puede verificar sus copias de seguridad desde la sección Copia de seguridad en la interfaz de usuario de ClusterControl:
Esperamos que esto le ayude a configurar mejor sus copias de seguridad de MySQL; puede descargar ClusterControl desde nuestro sitio web (es gratis).
