Pular para o conteúdo principal

Percona XtraBackup - Backup Físico MySQL



Perocona XtraBackup  é uma ferramenta open source que faz um hot backup físico da sua base MySQL sem parada do seu banco.

Então se você tem o MySQL na versão free, o XtraBackup pode te ajudar muito.  Com ele é possível realizar backups full, incremental, compactar e até criptografar os backups da sua base.

A ideia desse post é mostrar como é simples fazer backups usando a ferramenta XtraBackup. Maiores detalhes/instalação  aqui


Criando um backup full

Para iniciar o full, basta especificar o diretório que será guardado --target=dir. Se o diretório não existir, o xtrabackup irá criar, porém não irá sobrescrever se já existir arquivos na pasta.

xtrabackup --user=root --password=zabbix --backup --target-dir=/bkp/percona/


No final do backup você verá os valores (início e fim) dos LSN dos logs da sua base.
xtrabackup:  Redo log (from LSN 11930540802 to 11930753909) was copied


Preparando / Restaurando o backup

Antes de realizar o restore, existe a fase de preparação. Os arquivos de dados do banco não estão consistentes até que você realize a preparação. Lembra que fizemos o backup com a base de dados aberta? Pois é...durante a cópia podem ter ocorrido alterações na base. Então é necessário executar o xtrabackup com a opção --preprare e indicar onde foi feito seu backup --target-dir=/bkp/percona/


xtrabackup --prepare --target-dir=/bkp/percona

É recomendado não interromper o processo de preparação porque pode ocasionar corrupção e o backup pode ficar inutilizável.

Depois de terminada a fase de preparação, é só realizar a cópia (cp) para o datadir 
Caso prefira, o xtrabackup tem um funcionalidade para realizar a cópia.


xtrabackup --copy-back --target-dir=/data/

Caso esteja usando o MariaDB, um fork do MySQL, o XtraBackup funciona em algumas versão do MariaDB verifique aqui  a compatibilidade. Caso não queria usar o Percona, existe o utilitário Mariabackup. O uso é bem parecido confira aqui.



Comentários

Postagens mais visitadas deste blog

Configurando a política de retenção de backups no RMAN

                       Configurando a politica de reten çã o de backups no RMAN        O objetivo deste post é explicar como podemos configurar a reten çã o de backups na poderosa ferramenta de backup do bando de dados Oracle RMAN. Podemos configurar nossa pol í tica tendo por base dois tipos: janela de recupera çã o (recovery window) ou redundãncia (redundancy). Abaixo iremos abordar os dois tipos.       Para identificar qual dos dois tipos o RMAN está usando, use: RMAN> show retention policy; Política baseada em redundância CONFIGURE RETENTION POLICY TO REDUNDANCY 1; Política baseada em janela de recuperação CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 2 DAYS; ·        Política baseada em redund â ncia ( REDUNDANCY )       De uma maneira bem simples e objetiva, o par â met...

ORA-01623 ORA-00312 - Removendo redo logs

Após realizar um restore de um ambiente de Oracle RAC para um single instance usando snapshot de storage, tentei recriar os redo logs recebi o seguinte erro durante a exclusão de um grupo de discos. SQL> alter database drop logfile group 2; ORA-01623: o log 2 é o log atual para a instância UOW (thread 1) - não é possível eliminar ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.1638.1051804433' ORA-00312: thread 2 do log 1 on-line: '+DATA/UOW/ONLINELOG/group_2.981.1051804433' O erro quer dizer que o grupo de redo pertence a outra thread. Quer dizer que ele pertence a outra instância do ambiente RAC. Como no meu caso não precisarei mais dela, basta usar o comando: SAL> alter database disable thread 2; Database altered.   Usei o SQL abaixo para gerar os comandos para excluir os redo logs SQL> select distinct 'alter database drop logfile group '||(group#)||';' from v$log where thread#=2; 'ALTERDATABASEDROPLOGFILEGROUP'||(G...

Oracleasm Deletedisk - Unable to open device or resource busy failed Unable to clear disk

Após a migração de storages utilizando Oracle ASM em um ambiente, precisei remover os discos que não estavam mais sendo utilizados. Porém quando fui utilizar o deletedisk no oracleasm recebi o seguinte erro: # oracleasm deletedisk -v HITACHI33 Clearing disk header: oracleasm-write-label: Unable to open device "/dev/oracleasm/disks/HITACHI33": Device or resource busy failed Unable to clear disk "HITACHI33" Fiz a verificação para ver ser o disco ainda estava em uso, mas não obtive nenhum retorno: # fuser /dev/oracleasm/disks/HITACHI33 # lsof /dev/oracleasm/disks/HITACHI33 Então lendo alguns posts e artigos vi que o problema poderia estar relacionado ao multipath do sistema operacional. Então utilizei o -f para realizar um flush, mas recebi a mensagem abaixo: # multipath -f /dev/oracleasm/disks/HITACHI33 Jun 22 08:43:21 | must provide a map name to remove Utilizei o comando do ASM para verificar o mapeamento do disco....