Backups de banco de dados - Comparando MariaDB Mariabackup e Percona Xtrabackup

Seu servidor de banco de dados armazena algumas das informações mais valiosas de sua empresa. Garantir backups de banco de dados confiáveis para evitar perda de dados em caso de acidente ou falha de hardware é uma caixa de seleção crítica.

Seja um servidor altamente carregado 24 horas por dia, 7 dias por semana ou um ambiente de baixo volume de transações, você precisará tornar os backups um procedimento contínuo sem interromper o desempenho do servidor em um ambiente de produção.

Neste blog, revisaremos duas das ferramentas mais utilizadas para realizar essa tarefa, a saber, Percona XtraBackup e Mariabackup. Vamos rever as semelhanças e diferenças entre os dois, e também como usá-los.

O que é o Percona XtraBackup?

Percona XtraBackup é uma ferramenta de código aberto para realizar backups de bancos de dados MariaDB, MySQL e Percona Server. Ele executa backups completos sem bloqueio (para os mecanismos suportados), compactados e seguros em sistemas transacionais para que os aplicativos permaneçam totalmente disponíveis durante a janela de backup.

Usando esta ferramenta você pode:

Crie backups quentes do InnoDB, que são concluídos de forma rápida e confiável, sem pausar seu banco de dados ou adicionar carga ao servidor
Faça backups incrementais
Mover tabelas entre servidores MySQL on-line
Crie novos escravos de replicação MySQL facilmente
Transmita backups MySQL compactados para outro servidor
Economize espaço em disco e largura de banda de rede

O que é Mariabackup?

Mariabackup é uma ferramenta de código aberto fornecida pelo MariaDB para realizar backups físicos online. É um fork do Percona XtraBackup projetado para trabalhar com tabelas criptografadas e compactadas e é o método de backup recomendado para bancos de dados MariaDB.

O MariaDB Server 10.1 introduziu a compactação MariaDB e a criptografia de dados em repouso, mas as soluções de backup existentes não suportavam o recurso de backup completo para esses recursos. Assim, o MariaDB decidiu estender o XtraBackup (versão 2.3.8) e nomeou esta solução como Mariabackup.

Diferenças entre o Percona XtraBackup e o Mariabackup

Como observamos anteriormente, o Mariabackup é a ferramenta de backup recomendada para o MariaDB, e a principal diferença do XtraBackup é que ele funciona com tabelas criptografadas e compactadas.

De qualquer forma, se por algum motivo em particular você quiser usar o XtraBackup para seu banco de dados MariaDB, existem alguns pontos a serem considerados dependendo da versão do servidor MariaDB que você possui:

MariaDB 10.1:Com dados MariaDB não compactados e não criptografados, você pode usar o XtraBackup. Se a criptografia ou compactação for usada, ou quando innodb_page_size for definido com algum valor diferente de 16 K, não funcionará.
MariaDB 10.2:Você também pode tentar usar o XtraBackup, mas esteja ciente de que os problemas são provavelmente devido ao bug de incompatibilidade do formato de log de undo do MySQL 5.7 que foi corrigido no MariaDB 10.2.2. Devido a esse bug, os backups preparados com o XtraBackup podem falhar na recuperação de algumas transações. Somente se você executar o servidor com a configuração innodb_undo_logs=1 isso não será um problema.
MariaDB 10.3 e posterior:Este caso é mais simples. O XtraBackup não é compatível.

Além disso, existem algumas limitações a serem consideradas ao usar o Mariabackup:

MyRocks:A partir do MariaDB 10.2.16 e MariaDB 10.3.8, o Mariabackup fará backup dos dados do MyRocks Storage Engine. Atualmente, o backup parcial dos dados do MyRocks não é suportado. O backup incremental armazenará uma cópia completa dos dados do MyRocks.
Funcionalidade de exportação de arquivo:Antes do MariaDB 10.2.9, o Mariabackup não suportava a funcionalidade --export (ele cria um arquivo de exportação para exportar dados do banco de dados). Você pode contornar essa limitação preparando o backup normalmente (sem o sinalizador --export), depois inicie o servidor e execute FLUSH TABLES FOR EXPORT.
Arquivos de log:as versões do Mariabackup até 10.2.8 não criam arquivos de log vazios e dependem da ação --copy-back executada pelo usuário (que exclui arquivos de log innodb antigos, se houver). Se o usuário não usar --copy-back ou se certificar de que o diretório de dados está vazio antes de restaurar, os backups criados com essas versões podem ficar inconsistentes/corrompidos (devido à presença de logs InnoDB restantes).
Gcrypt:a criptografia baseada na ferramenta de backup (gcrypt) não é compatível com o Mariabackup.
Opção Innobackupex:Sem link simbólico para innobackupex (use o parâmetro --innobackupex). A ferramenta innobackupex corrige e fornece recursos adicionais sobre a ferramenta innobackup para fazer backup de tabelas InnoDB e MyISAM.
Opção compacta:a opção --compact não é compatível.
Opção de reconstrução de índices:a opção --rebuild_indexes não é suportada.
Tar para arquivos de backup:o suporte para --stream=tar foi removido no Mariabackup 10.1.24 (as opções --streams transmitem arquivos de backup para stdout).

Por último, mas não menos importante, o Mariabackup pode ser instalado no Windows.

Processo de backup

Restaurar processo

Como - Percona XtraBackup e Mariabackup

Vamos ver como podemos instalá-lo e usá-lo.

Instalação

Você tem métodos diferentes para instalar o XtraBackup e o Mariabackup. Vamos tentar a instalação a partir de repositórios.

Instalação do XtraBackup

No Debian/Ubuntu

$ wget https://repo.percona.com/apt/percona-release_0.1-6.$(lsb_release -sc)_all.deb
$ sudo dpkg -i percona-release_0.1-6.$(lsb_release -sc)_all.deb
$ sudo apt-get update
$ sudo apt-get install percona-xtrabackup-24

No RedHat/CentOS

$ sudo yum install http://www.percona.com/downloads/percona-release/redhat/0.1-6/percona-release-0.1-6.noarch.rpm
$ sudo yum install percona-xtrabackup-24

Instalação do Mariabackup

No Debian/Ubuntu

O Mariabackup faz parte do MariaDB Server a partir do MariaDB 10.1.23.

$ sudo apt-get install software-properties-common
$ sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
$ sudo add-apt-repository 'deb [arch=amd64,arm64,ppc64el] http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu bionic main'
$ sudo apt-get update
$ sudo apt-get install mariadb-server-10.1

No CentOS / RedHat

$ sudo vi /etc/yum.repos.d/MariaDB.repo
[mariadb]
name=MariaDB
baseurl=http://yum.mariadb.org/10.1/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1
$ sudo yum install MariaDB-backup

Configuração

Tanto o Xtrabackup quanto o Mariabackup leem as seções [mysqld] e [xtrabackup] de qualquer arquivo de configuração do MySQL, nessa ordem. Dessa forma, ele pode ler parâmetros MySQL, como datadir ou parâmetros InnoDB.

Podemos modificar os parâmetros incluídos na seção [mysqld] modificando seu valor em [xtrabackup], como mencionamos antes, eles são lidos em ordem, então a última coisa que temos em [xtrabackup] terá prioridade.

[mysqld]
datadir=/data/datadir
[xtrabackup]
target_dir=/backups/

O usuário com os privilégios mínimos necessários para backups completos seria RELOAD, LOCK TABLES, PROCESS e REPLICATION CLIENT:

mysql> CREATE USER 'backupuser'@'localhost' IDENTIFIED BY 'Password';
mysql> GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT ON *.* TO 'backupuser'@'localhost';

E então, você pode adicionar este usuário nos arquivos de configuração do MySQL:

[xtrabackup]
user=backupuser
password=Password

Além disso, você pode usar o Xtrabackup ou o Mariabackup para realizar as transferências de instantâneo de estado quando estiver usando um cluster Percona XtraDB ou um cluster MariaDB Galera. Você deve definir as variáveis wsrep_sst_method e wsrep_sst_auth nos arquivos de configuração:

[mysqld]
wsrep_sst_method=xtrabackup-v2
wsrep_sst_auth=backupuser:Password

[mysqld]
wsrep_sst_method=mariabackup
wsrep_sst_auth=backupuser:Password

Uso

Como o Mariabackup é baseado no XtraBackup, ele pode ser usado de forma semelhante.

Agora vamos ver um exemplo usando os dois métodos para criar, preparar e restaurar um backup completo.

Criando um backup

Para criar um novo backup com XtraBackup ou Mariabackup, você precisa adicionar as opções --backup e --target-dir à linha de comando:

$ xtrabackup --backup --target-dir=/backups/

$ mariabackup --backup --target-dir=/backups/

O diretório de destino, onde o backup será armazenado, pode ser especificado nos arquivos de configuração do MySQL. O processo de backup não substituirá os arquivos existentes. Se o arquivo existir, o backup falhará.

Transaction log of lsn (9755450) to (9755467) was copied.
181122 23:02:44 completed OK!

Se tudo correu bem, a última linha que você vê deve ser "concluído OK!". Você pode cancelar o backup a qualquer momento, pois ele não modifica o conteúdo do banco de dados.

[[email protected] ~]# ls -l /backups/
total 102448
-rw-r----- 1 root root       488 Nov 22 23:02 backup-my.cnf
-rw-r----- 1 root root       482 Nov 22 23:02 ib_buffer_pool
-rw-r----- 1 root root 104857600 Nov 22 23:02 ibdata1
drwxr-x--- 2 root root      4096 Nov 22 23:02 mysql
drwxr-x--- 2 root root      4096 Nov 22 23:02 performance_schema
drwxr-x--- 2 root root      4096 Nov 22 23:02 sakila
drwxr-x--- 2 root root     12288 Nov 22 23:02 sys
-rw-r----- 1 root root        64 Nov 22 23:02 xtrabackup_binlog_info
-rw-r----- 1 root root       113 Nov 22 23:02 xtrabackup_checkpoints
-rw-r----- 1 root root       533 Nov 22 23:02 xtrabackup_info
-rw-r----- 1 root root      2560 Nov 22 23:02 xtrabackup_logfile

Este deve ser o conteúdo do seu backup. Isso pode mudar dependendo de seus bancos de dados.

Preparando um backup

Quando você cria seu backup com o XtraBackup ou Mariabackup, precisa prepará-lo para ser restaurado. Os arquivos de dados não são consistentes até serem preparados, pois foram copiados em momentos diferentes durante o backup. Se você tentar restaurá-lo e iniciar seu banco de dados, ele detectará corrupção e travará para impedir que você execute dados inconsistentes.

Para preparar o backup, você precisa executar o comando xtrabackup ou mariabackup com a opção --prepare e especificar o diretório de destino onde está armazenado o backup.

$ xtrabackup --prepare --target-dir=/backups/

$ mariabackup --prepare --target-dir=/backups/
InnoDB: Shutdown completed; log sequence number 9757224
181122 23:05:29 completed OK!

A última linha que você vê deve ser "Desligamento concluído; número de sequência de log xxxxxxx" e "concluído OK!" se tudo correu bem. Não é recomendado cancelar o processo de preparação porque isso pode causar corrupção no arquivo de dados e o backup se tornará inutilizável.

Se você quiser usar esse backup com um backup incremental posteriormente, deverá usar a opção --apply-log-only ao prepará-lo, ou não poderá fazê-lo.

Restaurando um backup

Após preparar o backup, você pode usar a opção de restauração com os parâmetros --copy-back ou --move-back, para copiar ou mover o backup para o datadir. Se você não tiver espaço em disco suficiente, provavelmente deverá usar a opção mover. Além disso, precisamos especificar o diretório de destino onde o backup está armazenado. Lembre-se de que o datadir deve estar vazio e o serviço de banco de dados deve estar inativo antes de restaurar o backup.

$ xtrabackup --copy-back --target-dir=/backups/

$ mariabackup --copy-back --target-dir=/backups/

Ele primeiro copiará/moverá as tabelas e índices MyISAM, as tabelas e índices InnoDB em seguida e os arquivos de log por último. Ele preservará os atributos do arquivo ao copiá-los, talvez seja necessário alterar a propriedade dos arquivos para mysql antes de iniciar o servidor de banco de dados, pois eles serão de propriedade do usuário que criou o backup.

$ sudo chown -R mysql:mysql /var/lib/mysql

Existem vários parâmetros para usar com o Xtrabackup e o Mariabackup. Você pode verificar esses parâmetros aqui para o XtraBackup e aqui para o Mariabackup.
ClusterControlSingle Console para toda a sua infraestrutura de banco de dados Descubra o que mais há de novo no ClusterControlInstale o ClusterControl GRATUITAMENTE

Gerenciando seus backups no ClusterControl

Como vimos acima, executar um backup não é ciência de foguetes. Também pode ser agendado com o cron (mas cuidado com as falhas silenciosas!). No entanto, um script para criar backups regularmente não é uma solução de gerenciamento de backup. Você precisa de uma maneira de relatar seus backups e alertar sobre falhas. Agora, configurar backups em seu ambiente e ver os backups funcionando sem erros não significa que está tudo bem. Você pode ter ouvido falar sobre o backup de Schrödinger, que afirma que a condição de qualquer backup é desconhecida até que uma restauração seja tentada. Porque a pior coisa que pode acontecer é um desastre e você percebe que os backups estão errados por algum motivo. Você tenta restaurar os arquivos dos quais foi feito backup e ele não restaura o que você acha que fez backup ou não restaura nada! Depois, há coisas como mover arquivos de backup para fora do local, por exemplo, para armazenamento em nuvem externa, para recuperação de desastres. A criptografia e o manuseio de chaves são importantes para a segurança. A retenção de backups locais e externos/arquivados também precisa ser gerenciada.

Vamos ver como o ClusterControl pode ajudar.

Se você quiser usar o recurso ClusterControl Backup, vá para ClusterControl -> Select Cluster -> Backup, e lá você pode ver seus backups atuais, criar ou agendar um novo.

Seção de backup do ClusterControl
Usando a opção criar ou agendar, podemos escolher o método XtraBackup ou Mariabackup. Na mesma seção, podemos escolher o servidor do qual fazer o backup, habilitar o backup parcial, escolher onde deseja armazenar o backup e se deseja fazer o upload do backup para a nuvem (AWS, Azure ou Google Cloud).

ClusterControl Criar Backup 1
Em seguida, podemos selecionar parâmetros de backup como compactação, criptografia e retenção.

ClusterControl Criar Backup 2
E estes devem ser os comandos que o ClusterControl irá executar para você:

[16:37:58]: 192.168.100.120: Launching ( LC_ALL=C /usr/bin/innobackupex --defaults-file=/etc/my.cnf --galera-info --parallel 1 --stream=xbstream --no-timestamp . | gzip -6 - > /root/backups/BACKUP-13/backup-full-2018-11-14_193757.xbstream.gz ) 2>&1.

[16:29:57]: 192.168.100.131: Launching ( LC_ALL=C /usr/bin/mariabackup --defaults-file=/etc/my.cnf --backup --galera-info --parallel 1 --stream=xbstream --no-timestamp | gzip -6 - > /root/backups/BACKUP-11/backup-full-2018-11-14_192957.xbstream.gz ) 2>&1.

Este comando pode ser diferente dependendo de quais parâmetros você escolheu.

Como pudemos ver, o ClusterControl é um bom amigo se quisermos usar o XtraBackup ou o Mariabackup. Podemos executar comandos de backup complexos de maneira fácil, selecionando as opções da interface do ClusterControl.
O ClusterControl suporta backup completo ou incremental, para que possamos configurar toda a nossa estratégia de backup a partir de uma interface amigável.

Conclusão

Ao fazer backup de um servidor MariaDB, é recomendável usar a ferramenta Mariabackup. No entanto, se por algum motivo você preferir usar o XtraBackup, ainda poderá. Mas você precisa ter em mente as restrições que se aplicam, como observamos neste blog. E, finalmente, discutimos como um script para fazer backup de um banco de dados não é a mesma coisa que uma solução de gerenciamento de backup e demos uma olhada rápida no ClusterControl.

Deixe-nos saber se perdemos alguma diferença entre o XtraBackup e o MariaBackup.

Os backups sem bloqueio são compatíveis com os mecanismos de armazenamento InnoDB, XtraDB e HailDB. O backup dos seguintes mecanismos de armazenamento pode ser feito pausando brevemente as gravações no final do backup:MyISAM, Merge e Archive, incluindo tabelas particionadas, gatilhos e opções de banco de dados.