Estratégias bem-sucedidas de backup e recuperação MySQL/MariaDB

Uma parte vital da prevenção de qualquer tipo de perda de dados em qualquer situação é ter políticas adequadas de backup e recuperação. Também é essencial garantir a recuperação de dados em qualquer momento do ciclo de vida do fluxo de trabalho do aplicativo. Tanto o MySQL quanto o MariaDB oferecem soluções para esses casos. Este artigo explorará as opções e procedimentos existentes, bem como outras opções de backup em potencial para MySQL e MariaDB.

Estratégias de backup

Como os dados são a parte mais importante de qualquer aplicativo, proteger sua integridade é vital para sobreviver na batalha da existência. Qualquer interrupção da acessibilidade ou integridade dos dados a qualquer momento provavelmente prejudicará gravemente o aplicativo e o negócio/serviço que está fornecendo.

Para garantir o fluxo de trabalho de aplicativos bem-sucedido e a continuidade dos negócios, você precisa implementar políticas adequadas de backup e recuperação com backups diários, semanais, mensais e anuais. Esses backups serão executados em períodos críticos, como:

antes de uma janela de lote diária;
antes de ingestões de dados em massa;
antes de qualquer atualização de aplicativo;
backups semanais, mensais e anuais para atender aos requisitos regulamentares;
ou outra manutenção programada diária/semanal.

Ferramentas de backup

MySQL e MariaDB oferecem várias maneiras de configurar e executar planos de backup e recuperação. Esses métodos incluem backups físicos com a ferramenta mysqlbackup empresarial do MySQL , ferramenta mariabackup do MariaDB , ou ferramenta XtraBackup da Percona . Além disso, backups lógicos criados com a ferramenta mysqldump do MySQL pode vir a calhar. Outra opção é a recuperação pontual com os logs bin dos bancos de dados (os logs de transações) em combinação com as ferramentas mencionadas anteriormente.

Você pode assimilar métodos adequados em sua estratégia de backup para maximizar a capacidade de recuperação do banco de dados em caso de falha ou desastre.

Nota:Na versão 10.4.6 do MariaDB, link simbólico do mysqldump chama-se mariadb-dump . Nas versões posteriores, incluindo 10.5.2, os nomes mudaram novamente – mysqldump tornou-se link simbólico .

Para ilustrar os procedimentos, usarei a ferramenta mariabackup para criar backups físicos. A funcionalidade básica da ferramenta é a mesma das ferramentas mencionadas, embora existam algumas pequenas diferenças exclusivas para cada ferramenta.

Backups de banco de dados físico

Os backups físicos são backups em nível de arquivo que fornecem métodos rápidos de cópia de arquivos. Esses backups são preferíveis em cenários de recuperação de desastres, clonagem de bancos de dados e/ou criação de bancos de dados escravos.

Ao fazer backups físicos, você pode optar por criar backups completos ou incrementais. Os backups completos incluem um backup completo do servidor de banco de dados. Os backups incrementais salvam as alterações apenas do último backup completo ou incremental.

Importante:O tamanho do banco de dados regula o tempo do backup. Por esse motivo, uma boa estratégia para fazer backup de um banco de dados muito grande pode ser combinar backups completos e incrementais. Dessa forma, você economiza o espaço de armazenamento dos backups e o tempo total de backup e recuperação.

Outro momento que você deve observar é que ao recuperar os dados de um backup físico, você deve interromper o processo de instância do banco de dados MySQL/MariaDB até que as etapas finais de recuperação sejam concluídas.

Você pode realizar a execução de um backup físico completo simples da seguinte forma:

 mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220 \
   --user=backupuser --password=backuppasswd

O –diretório-alvo opção informa à ferramenta de backup onde colocar o backup.

Neste exemplo, organizei meu backup no diretório chamado DYYYYMMDD onde cada backup completo é armazenado (D significa Diário). Ao fazer isso, temos um curso de ação fácil para restaurar o banco de dados do backup feito em uma data específica.

O próximo exemplo demonstra a execução de um backup incremental simples:

mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220_inc1/ \
   --incremental-basedir=/data/backups/mariadb/D20210220/ \
   --user=backupuser --password=backuppasswd

O backup incremental subsequente teria a seguinte aparência:

mariabackup --backup \
   --target-dir=/data/backups/mariadb/D20210220_inc2/ \
   --incremental-basedir=/data/backups/mariadb/D20210220_inc1 \
   --user=backupuser --password=backuppasswd

O –incremental-basedir A opção instrui a ferramenta de backup a usar o backup completo ou incremental feito anteriormente como ponto de partida na criação de arquivos delta incrementais para o backup atual. Dessa forma, ele cria uma cadeia de um backup completo com backups incrementais subsequentes. Juntos, eles formam um único backup para restaurar quando necessário.

Agora, vamos descobrir qual é o nome do arquivo de banco de dados físico no qual todos os dados do diretório estão armazenados. O banco de dados localizado nos controladores de domínio é um Active Directory. Este diretório é usado para gerenciar usuários, dados, etc. O núcleo de um Active Directory é o arquivo de banco de dados NTDS.DIT que consiste em link, descritor de segurança e tabelas de dados. Todos os dados do diretório são mantidos neste arquivo de banco de dados físico.

É necessário distinguir entre arquivos físicos e lógicos. Os dados reais do sistema estão localizados em arquivos físicos, enquanto os arquivos lógicos contêm a descrição dos registros armazenados em arquivos físicos.

A tarefa de restaurar o banco de dados MySQL a partir de arquivos físicos pode ser difícil às vezes. O mysqldump comando pode ser útil neste caso. Abordaremos este tópico mais adiante.

Backups de banco de dados lógico

Os backups lógicos são criados com o mysqldump ferramenta. Esse método de backup é mais flexível que o backup físico. Ele consiste em todas as instruções SQL DML e/ou DDL necessárias para formar um backup consistente, combinando todos os dados confirmados e as alterações feitas antes e durante o backup. Se você quiser saber mais sobre como fazer backup e restaurar todos os bancos de dados, leia este artigo.

O backup lógico pode ser um único arquivo ou vários arquivos (criados com um script específico). Além disso, você pode restaurar a estrutura e/ou dados sem encerrar sua instância MySQL/MariaDB (processo). Assim, os backups lógicos são executados em nível de banco de dados e/ou tabela, enquanto os backups físicos são realizados em nível de sistema de arquivos (diretórios e arquivos).

Observe também que os backups lógicos são exclusivamente imagens de backups completos dos bancos de dados e/ou tabelas pretendidos.

A criação de um backup lógico de toda a instância MySQL/MariaDB está abaixo:

mysqldump --all-databases --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/full-backup-$(date +'%Y%m%d_%H%M%S').sql

Observe que os backups físicos e os backups lógicos são diferenciados especificamente no sistema de arquivos para fins de gerenciamento de backup.

Ao contrário do exemplo anterior, um backup lógico de um único banco de dados (esquema) é criado da seguinte maneira:

mysqldump empdb --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-full-backup-$(date +'%Y%m%d_%H%M%S').sql

Por fim, para criar um backup lógico de uma única tabela em um banco de dados, adicione o nome da tabela após o banco de dados:

mysqldump empdb departments --single-transaction \
 --quick --lock-tables=false \
 -u backupuser -p backuppasswd \
> /data/backups/mariadb/logical/D20210220/empdb-departments-full-backup-$(date +'%Y%m%d_%H%M%S').sql

Quando você precisar editar e adicionar as instruções DROP DATABASE ou DROP TABLE ao cenário de recuperação, trabalhar com arquivos de backup grandes pode ter efeitos restritivos nos editores de texto a ponto de engasgá-los.

Nesses casos, considere adicionar outras opções, como –add-drop-database e/ou –add-drop-table para incluir essas instruções DROP no backup. Em outros cenários, você pode querer excluir essas instruções e substituí-las pela –skip-add-drop-table opção ao comando.

No entanto, você também pode criar os backups somente de dados ou somente DDL usando –no-create-info ou –sem dados opções. Backups separados de dados e estrutura podem ser uma boa opção em alguns cenários de recuperação, especialmente quando você só precisa da estrutura DDL para criar um banco de dados clonado vazio e/ou suas tabelas.

Fazendo backup do banco de dados usando instantâneos de disco

À medida que os dados crescem, pode ser necessário organizá-los em vários discos e/ou sistemas de arquivos. Além dos motivos de desempenho, como a E/S é distribuída em vários discos/sistemas de arquivos, você precisa garantir que as estratégias eficientes de backup e recuperação incluam os recursos de captura instantânea de disco e sistema de arquivos.

Comece projetando e construindo os layouts do sistema de arquivos onde residem cada banco de dados, grupo de tabelas e índices. Em seguida, organize suas tabelas e configure o sistema de banco de dados. Eles devem residir todos em um único diretório:

innodb_home_dir = /<path where your InnoDB tables will reside>

Ou você pode usar o DATA_DIRECTORY e INDEX_DIRECTORY opções em CRIAR table para distribuí-los separadamente para diferentes locais do sistema de arquivos.

Para InnoDB, certifique-se de usar file_per_table =ON (padrão ON nas versões mais recentes). Escolha o caminho para as tabelas do InnoDB com cuidado ao criá-las. É impossível alterar o caminho sem descartar e recriar a tabela.

É útil ter sistemas de arquivos adequados com recursos de instantâneos integrados, por exemplo, XFS e ZFS no Linux. Observe que a criação de backups de snapshots é semelhante à criação de backups físicos, mas possui especificidades. Requer parar o processo de escrita (FLUSH com READ LOCK ou similar — veja a ESTÁGIO DE BACKUP comando na documentação online do MariaDB) antes de tirar o snapshot e liberar LOCKS imediatamente após a conclusão do instantâneo. É necessário garantir a consistência dos dados.

Você deve considerar e usar os backups de instantâneos em cenários de recuperação de desastres. No entanto, eles também são adequados para clonar instâncias de banco de dados.

Estratégias de recuperação

Recuperação de backups físicos

Anteriormente, descrevemos as etapas de backup físico. Dessa forma, você pode construir uma cadeia de backups completos ou uma cadeia de backups completos e incrementais. A última opção significa que um backup completo seguido por um backup incremental subsequente é o ponto zero se ocorrer uma falha.

Por exemplo, um DBA faz backups completos aos domingos e backups incrementais nos outros dias. Ocorre uma falha após fazer um backup incremental na quarta-feira. Portanto, eles precisam restaurar o banco de dados. Sob tais circunstâncias, nosso DBA deve usar o backup completo feito no domingo e os backups incrementais feitos na segunda, terça e quarta-feira. Se houvesse backups completos diários, seria suficiente restaurar o backup de quarta-feira.

Para recuperar o backup “mais próximo” após uma falha, seja um backup completo ou incremental, você precisa garantir que TODOS os arquivos de backup sejam consistentes com o momento com a hora do término de backup mais próximo. Caso contrário, o mecanismo InnoDB rejeitará os dados por considerá-los corrompidos.

Outro ponto importante é que, ao preparar backups, copie os backups completos envolvidos para outro local antes de aplicar as etapas para garantir a consistência pontual. Dessa forma, você preserva o estado de backup original, que pode ser útil mais tarde. Eu recomendo fortemente usar essa abordagem.

Para preparar um backup completo, escolha o mais próximo da falha, copie-o para o local de sua preferência e execute o seguinte comando:

mariabackup --prepare \
   --target-dir=data/backups/mariadb/COPY_D20210220

Para restaurar para o backup incremental mais próximo, prepare uma cópia do backup completo mais próximo e adicione todos os backups incrementais relevantes em um pedido subsequente . A imagem de banco de dados restaurada deve ser a seguinte:

Conseguimos isso executando o prepare comando para cada backup incremental conforme mostrado abaixo:

mariabackup --prepare \
   --target-dir=/data/backups/mariadb/COPY_D20210220 \
   --incremental-dir=/data/backups/mariadb/D20210220_INC#

Depois de preparar a cópia de backup, devemos encerrar a instância do banco de dados (processo). Além disso, devemos esvaziar o diretório de banco de dados antes de terminar o processo de restauração. Você pode emitir o comando com o –copy-back opção

mariabackup --copy-back \
   --target-dir=data/backups/mariadb/COPY_D20210220

ou com o –mover-back opção:

mariabackup --move-back \
   --target-dir=data/backups/mariadb/COPY_D20210220

O último comando move o diretório copiado para o diretório do banco de dados. Copiar o backup original para outro local é uma escolha sábia. Caso contrário, o backup será perdido, pois não poderá usá-lo para outras situações e cenários.

A última etapa antes de iniciar a instância do banco de dados é ajustar a propriedade dos arquivos para corresponder ao usuário e ao grupo do proprietário do processo. Normalmente, é o MySQL.

Recuperação de backups lógicos

Muitas vezes, ignoramos um ponto-chave ao recuperar bancos de dados e/ou tabelas usando backups lógicos. Este ponto está configurando o max_allowed_packet tamanho da sessão (pode ser mais sensato defini-lo globalmente) para o valor máximo de 1073741824. É necessário garantir que buffers grandes e instruções INSERT caibam em um único pacote entre o cliente e o servidor. Isso deve reduzir o tempo de recuperação.

Outro aspecto importante ao fazer um backup é incluir ou excluir as instruções DROP, conforme mencionado anteriormente. Precisamos dele para garantir a execução do processo de restauração de backup da maneira mais suave possível. Com isso em mente, use o código abaixo para executar a restauração de backup:

mysql -u backupuser -p backuppasswd  < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sql

Se você não tiver nenhum banco de dados incluído no backup, como em backups de banco de dados individuais, ou precisar redirecionar a restauração para outro banco de dados, use um código diferente:

mysql -u backupuser -p backuppasswd  newemp < /data/backups/mariadb/logical/D20210220/emp-full-backup-20210228_153726.sql

Recuperação com instantâneos de disco

Para recuperar do instantâneo de disco sempre comece garantindo que o sistema de banco de dados é desligado antes o processo de recuperação é executado . Qualquer tentativa de recuperar um banco de dados ativo usando o instantâneo de disco resultará em inconsistências de dados e, mais provavelmente, em corrupção de dados.

Recuperação pontual

A recuperação pontual (PITR) é, como o nome indica, um método para recuperar bancos de dados e tabelas o mais próximo possível do tempo anterior à falha. Ou, se o processo em lote diário falhou e precisa ser executado novamente, você também tem a única opção – fazer a recuperação de backup PITR.

É vital habilitar o log bin do banco de dados e definir o formato do log bin para o log baseado em instrução, baseado em linha ou misto, dependendo do tipo de carga de trabalho que seu banco de dados está executando. Além disso, pode ser necessário ativar a compactação usando log_bin_compress =ON (padrão OFF) para economizar espaço em disco.

Como bin-log é um log de transações e criado em uma sequência, é fundamental fazer um backup de todos os arquivos de log. Quanto ao processo PITR, é impossível sem arquivos de log. Além disso, a manutenção do log bin e o ciclo de vida devem seguir o ciclo de vida de quaisquer backups completos e incrementais. Portanto, certifique-se de limpar apenas os logs mais antigos que o backup mais antigo na política de backup.

Você pode limpar os logs binários de duas maneiras. Primeiro, é declarando o nome do log bin mais próximo para o backup mais antigo, conforme mostrado no comando purge abaixo:

PURGE BINARY LOGS TO 'mariadb-bin.000063';

Segundo, é declarando a data do backup mais antigo mantido no comando purge:

PURGE BINARY LOGS BEFORE '2021-01-20 00:00:00';

Para nos prepararmos para a recuperação, precisamos recuperar todas as instruções necessárias para reproduzir até o momento necessário. Colete todos os logs bin disponíveis desde o momento em que o backup foi iniciado até o momento em que você está recuperando.

Comece examinando a lista de logs desde a hora em que o backup terminou até a hora do PITR:

mysqlbinlog --start-datetime=<backup end datetime> --stop-datetime=<PITR datetime> \
<list of binlogs> \
> temporary_file.sql

Em seguida, examine os arquivos temporários para localizar as posições de log exatas que deseja aplicar e usar. Estes são –posição inicial e –stop-position que define as posições exatas no comando e executa novamente o mysqlbinlog comando:

mysqlbinlog --start-position=<exact log start position> --stop-position=<exact log position to stop on> \
<list of binlogs> \
> final_temporary_PITR_file.sql

Neste ponto, o processo de recuperação começou. Ele usa backups físicos ou lógicos, completos ou incrementais.

Conclua a recuperação aplicando o final_temporary_PITR_file.sql usando o cliente MySQL como mostrado abaixo:

mysql -u backupuser -p backuppasswd < final_temporary_PTR_file.sql

Concluímos a recuperação do PITR restaurando o backup e as transações repetidas do log para o ponto mais próximo do momento da ocorrência da falha.

Banco de trabalho

Para projeto e desenvolvimento de banco de dados, teste e manutenção em MySQL e MariaDB, podemos usar um aplicativo do Windows Workbench. Funciona também no Linux. Com este aplicativo, os usuários podem projetar bancos de dados, visualizar e alterar metadados, transferir dados e metadados e muito mais. Vale acrescentar que é possível usar o dbForge Studio for MySQL em vez do Workbench.

Conclusão

Ao todo, discutimos e ilustramos brevemente as técnicas de backup e recuperação de banco de dados com ferramentas e métodos disponíveis em MySQL e MariaDB.

Para recuperar o sistema de banco de dados de qualquer falha com sucesso, devemos implementar backup físico e lógico métodos mencionados acima nas políticas e planos, desde todo o sistema até tabelas individuais.

Para realizar um PITR com sucesso, precisamos de bin-log habilitado e necessidades de gerenciamento de log adequados no lugar.

No entanto, usar apenas um método de backup e logs bin ausentes seria a abordagem errada. Isso pode resultar em perda de dados e prejudicar a continuidade dos negócios do seu aplicativo. Assim, combine diferentes métodos e sempre inclua os arquivos de log nas políticas de backup e restauração!