O recurso de gerenciamento de backup centralizado do ClusterControl suporta o mysqldump padrão, backup Percona Xtrabackup e Mariabackup fornecidos pelo MariaDB. Acreditamos que os argumentos de linha de comando escolhidos para os respectivos métodos são ideais para a maioria das cargas de trabalho de banco de dados e estão em conformidade com as práticas recomendadas de backup do MySQL. Baseamo-nos em todos os comentários que recebemos ao longo dos anos, ao trabalhar com DBAs e administradores de sistema. No entanto, a configuração pode não ser suficiente em algumas circunstâncias. Você ainda pode querer personalizá-lo para se adequar ao seu ambiente, usando o respectivo método de backup. Neste post, mostraremos como fazer isso.
mysqldump
Para executar um backup da interface do usuário do ClusterControl, vá para ClusterControl -> Select Cluster -> seção Backup. Aqui você pode ver os backups gerados e pode criar ou agendar um novo.
Na UI do ClusterControl, temos algumas opções diferentes para fazer o backup. Podemos criar um dumpfile para cada banco de dados, habilitar backup parcial, armazenar o backup no nó ou no servidor ClusterControl; podemos especificar o diretório e subdiretório de backup, ou podemos arquivar automaticamente o backup na nuvem (AWS, Google Cloud ou Azure) usando o recurso de upload na nuvem.
Além disso, podemos usar compactação, criptografar nosso backup e especificar o período de retenção.
Por padrão, o ClusterControl nos permite escolher entre 4 tipos diferentes de dump para realizar o backup:
- Esquema e dados:esquema e dados do banco de dados
- Somente esquema:esquema de banco de dados
- Somente dados:dados do banco de dados
- Somente banco de dados MySQL:banco de dados do sistema MySQL
Digamos que temos 5 bancos de dados e escolhemos fazer backup de todos eles. Aqui está o que o ClusterControl executará ao realizar o backup usando o método mysqldump (os comandos são cortados com barra invertida para facilitar a leitura):
- Esquema e dados
$ /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'.
- Apenas 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'.
- Somente dados
$ /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'.
- Somente banco de dados 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'.
Se nosso nó MySQL estiver gerando logs binários, teremos o parâmetro master-data=2 incluído nos comandos acima e 1 tipo de dump extra disponível:
- Complete compatível com 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'.
A partir das linhas de comando acima, podemos ver que em cada comando mysqldump, o ClusterControl inclui o arquivo de configuração do MySQL em seu argumento --defaults-file. Com isso, o processo mysqldump é capaz de ler o conteúdo da diretiva mysqldump. Por padrão, o ClusterControl configura as credenciais do usuário de backup em um arquivo separado em /etc/my.cnf.d/secrets-backup.cnf e o max_allowed_packet em my.cnf, semelhante ao seguinte:
$ my.cnf
[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8
$ secrets-backup.cnf
[mysqldump]
user=backupuser
password=ETgAG5VnpvuyXniE
A vantagem disso é que podemos incluir algumas opções extras para mysqldump. Infelizmente, o argumento --defaults-file só pode ser especificado como o argumento principal. Preste atenção que os últimos argumentos de linha de comando têm precedência sobre o que foi configurado dentro de my.cnf sob a diretiva [mysqldump] com base na ordem em que aparecem. Por exemplo, se adicionarmos skip-comments=0 dentro de my.cnf, enquanto no final do comando mysqldump há um --skip-comments (ou --skip-comments=1), o primeiro será ignorado e este último será usado.
No entanto, ainda podemos usá-lo como parte de nossa personalização de backup usando outras opções de backup do mysqldump. Por exemplo, podemos excluir tabelas que não queremos fazer backup usando o parâmetro ignore-table (com formatação “database.table”). Adicione as seguintes linhas ao arquivo de configuração do MySQL:
[mysqldump]
max_allowed_packet = 512M
# default_character_set = utf8
ignore-table=sbtest.sbtest9
ignore-table=sbtest.sbtest10
ignore-table=sbtest.sbtest1
Uma vez configurado, podemos apenas acionar um novo trabalho mysqldump do ClusterControl e teremos essas tabelas ignoradas pelo mysqldump. Nenhuma reinicialização do MySQL é necessária.
Você pode verificar a documentação do mysqldump para obter mais informações.
Percona Xtrabackup
O ClusterControl executa o Xtrabackup dependendo das opções que você escolheu. Ele pode ser completo ou incremental e você pode escolher várias variáveis da interface do usuário do ClusterControl. Considere o seguinte:
Nesta etapa você pode escolher algumas variáveis que mencionamos anteriormente na seção mysqldump e depois:
Podemos especificar alguns detalhes como nó de dessincronização durante o backup, Xtrabackup Parallel Copy Threads e muito mais.
Com base nas opções acima, o comando completo do Xtrabackup seria:
$ 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.
O primeiro comando “ulimit -n 256000” é garantir que o Percona Xtrabackup tenha privilégios suficientes para acessar um grande número de descritores de arquivos (caso os bancos de dados contenham muitas tabelas). Observe o --defaults-file=/etc/mysql/my.cnf, que é semelhante ao mysqldump, onde innobackupex lê o conteúdo da configuração do MySQL nas seguintes diretivas e variáveis:
[mysqld]
datadir=[physical path to MySQL data directory]
tmpdir=[path to temporary directory]
[xtrabackup]
user=backupuser
password=[random password]
Se você quiser personalizar as opções de backup para o Percona Xtrabackup, você pode adicioná-las diretamente na diretiva [xtrabackup]. Por exemplo, digamos que queremos que o Xtrabackup imprima a posição do log binário quando o backup for feito, podemos adicionar algo assim:
[xtrabackup]
user=backupuser
password=[random password]
slave-info=1
Acionar o trabalho xtrabackup incluirá um arquivo chamado arquivo xtrabackup_slave_info. Nenhuma reinicialização do MySQL é necessária.
Você pode verificar a documentação do Percona para obter mais informações sobre como ele funciona.
Mariabackup
O Mariabackup é um fork do Percona XtraBackup com suporte adicional para compactação MariaDB 10.1 e criptografia de dados em repouso. Ele está incluído no MariaDB 10.1.23 e posterior.
O método de backup pode ser completo ou incremental e você pode selecionar as mesmas variáveis que você tem para o Percona XtraBackup, como Compressão, Threads de Cópia Paralela do Xtrabackup ou Criptografia.
O comando Mariabackup seria:
$ /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.
O Mariabackup é baseado no Percona XtraBackup, portanto, usa as mesmas informações que o Percona para realizar o backup. Por padrão, o ClusterControl adiciona as seguintes linhas no arquivo my.cnf:
[xtrabackup]
databases-exclude=lost+found
# ssl_mode = DISABLED
ssl = 0
E as credenciais no arquivo secrets-backup.cnf:
[xtrabackup]
user=backupuser
password=[random password]
Se você quiser adicionar alguma variável, você pode adicioná-la na seção [xtrabackup].
Você pode verificar a documentação do MariaDB para obter mais informações sobre qual parâmetro adicionar.
Em cada caso, você pode verificar seus backups na seção Backup na interface do usuário do ClusterControl:
Esperamos que isso ajude você a configurar melhor seus backups do MySQL - você pode baixar o ClusterControl do nosso site (é grátis).