Meu último post referente a backups foi a bastante tempo atrás. Embora ainda válido, não é aconselhável para ser utilizado como backup diário, então resolvi mostrar uma outra opção, o XtraBackup.
Com XtraBackup, você pode realizar backups sem interromper leituras e escritas (ele requer lock por um período bem curto de tempo para pegar coordenadas do binlog).
Hoje vou mostrar como realizar backup completos utilizando a ferramenta.
Instalação:
Para realizar a instalação, eu aconselho utilizar os repositórios para Yum / Apt-get:
Centos / Redhat:
sudo yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm sudo yum install percona-xtrabackup-24
Debian / Ubuntu
wget https://repo.percona.com/apt/percona-release_0.1-4.$(lsb_release -sc)_all.deb sudo dpkg -i percona-release_0.1-4.$(lsb_release -sc)_all.deb sudo apt-get update sudo apt-get install percona-xtrabackup-24
Backup:
Para realizar o backup, vamos usar o script innobackupex:
innobackupex --user=root --password='Passw0rd!' /backups/
O script irá produzir várias mensagens, devemos verificar se ele termina com:
... 170429 21:07:12 completed OK!
Paralelismo:
O Xtrabackup permite que você configure múltiplas threads para realizar a cópia das tabelas utilizando a opção –parallel :
innobackupex --user=root --password='Passw0rd!' --parallel=8 /backups/
Podemos observar que cada thread recebe um número que é mostrado entre []:
170429 21:12:27 [05] Copying ./ibdata1 to /backups/2017-04-29_21-12-27/ibdata1 170429 21:12:27 [06] Copying ./mysql/plugin.ibd to /backups/2017-04-29_21-12-27/mysql/plugin.ibd 170429 21:12:27 [06] ...done 170429 21:12:27 [02] Copying ./mysql/servers.ibd to /backups/2017-04-29_21-12-27/mysql/servers.ibd 170429 21:12:27 [02] ...done 170429 21:12:27 [03] Copying ./mysql/help_topic.ibd to /backups/2017-04-29_21-12-27/mysql/help_topic.ibd 170429 21:12:27 [07] Copying ./mysql/help_category.ibd to /backups/2017-04-29_21-12-27/mysql/help_category.ibd 170429 21:12:27 [07] ...done
Compactando:
O Xtrabackup também permite que você compacte o backup utilizando –compress e –compress-threads (normalmente utiliza-se o mesmo numero de threads que –parallel):
innobackupex --user=root --password='Passw0rd!' --parallel=8 --compress --compress-threads=8 /backups/
Por exemplo, um backup que ocupava 702M passa a ocupar 387M compactado:
702M /backups/2017-04-29_21-12-27 387M /backups/2017-04-29_21-15-53
Restaurando:
Para restaurar o backup, temos que (1) descompactar com –decompress caso nosso backup seja compactado(você precisa ter o qpress instalado) e (2) aplicar as transações que ocorreram enquanto o backup estava sendo realizado (Basicamente um crash recovery que o InnoDB faz ao iniciar o MySQL):
innobackupex --decompress /backups/2017-04-29_21-18-04/ innobackupex --apply-log --use-memory=4G /backups/2017-04-29_21-18-04
Para agilizar o processo de aplicar os logs, podemos configurar –use-memory que vai se comportar como se fosse o InnoDB Buffer Pool.
Os arquivos .qp vao continuar no diretório, você pode remove-los manualmente executando o comando abaixo:
find /backups/2017-04-29_21-18-04 -name "*.qp" -exec rm -f {} \;
É isso aí. Agora só precisamos copiar os arquivos para o datadir do MySQL e configurar o usuário mysql para ser o owner e group owner da pasta e de todos os arquivos.
Por hoje é só. E lembrem, Backup que não é testado, NÃO É BACKUP!