Mysql
 sql >> Base de Dados >  >> RDS >> Mysql

Como personalizar seus backups MySQL e MariaDB com ClusterControl


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).