A realização de backups regulares do cluster de banco de dados é essencial para alta disponibilidade e recuperação de desastres. Se, por algum motivo, você perder todo o cluster e precisar fazer uma restauração completa do backup, precisará de um backup confiável e atualizado para começar.
Práticas recomendadas para backups
Algumas recomendações a serem consideradas para um bom regime de backup agendado:
- Você deve conseguir se recuperar completamente de uma falha catastrófica de pelo menos dois backups completos anteriores. Caso o backup completo mais recente esteja danificado, perdido ou corrompido,
- Seu backup deve conter pelo menos um backup completo dentro de um ciclo escolhido, normalmente semanal,
- Armazene backups longe do local de dados atual, de preferência fora do local,
- Use uma mistura de mysqldump e Xtrabackup para segurança extra e não confie em um método,
- Teste a restauração de seus backups regularmente, por exemplo, a cada dois meses.
Normalmente, um backup completo semanal combinado com um backup incremental diário é suficiente. Manter vários backups por um período de tempo é sempre um bom plano, talvez mantenha cada backup semanal por um mês. Isso permite que você recupere um banco de dados mais antigo em caso de emergências ou se, por algum motivo, houver corrupção no arquivo de backup local.
mysqldump ou Xtrabackup
mysqldump é muito provavelmente a maneira mais popular de fazer backup do MySQL. Ele faz um backup lógico dos dados, lendo cada tabela usando instruções SQL e exportando os dados para arquivos de texto. Restauração de um mysqldump é tão fácil quanto criar o arquivo de despejo. As principais desvantagens são que ele é muito lento para bancos de dados grandes, não é "quente" e elimina o buffer pool do InnoDB.
O Xtrabackup executa backups a quente, não bloqueia o banco de dados durante o backup e geralmente é mais rápido. Os backups a quente são importantes para alta disponibilidade, pois são executados sem bloquear o aplicativo. Este também é um fator importante quando usado com o Galera, pois o Galera depende da replicação síncrona. No entanto, restaurar um xtrabackup pode ser um pouco complicado usando maneiras manuais.
O ClusterControl suporta o agendamento de mysqldump e Xtrabackup (completo e incremental), bem como a restauração de backup diretamente da interface do usuário.
Restauração completa do backup
Neste post, mostraremos como restaurar o Xtrabackup (completo + incremental) em um cluster vazio em execução no MariaDB Galera Cluster. Essas etapas também devem funcionar no Percona XtraDB Cluster ou Galera Cluster for MySQL da Codership.
Em nosso cluster original, tínhamos um xtrabackup completo agendado diariamente, com backups incrementais criados a cada hora. Os backups são armazenados no ClusterControl conforme mostrado na captura de tela a seguir:
Agora, vamos supor que perdemos nosso cluster original e precisamos fazer uma restauração completa em um novo cluster. As etapas incluem:
- Configure um novo servidor ClusterControl.
- Configure um novo cluster MariaDB.
- Exporte os registros e arquivos de backup para o novo servidor ClusterControl.
- Inicie o processo de restauração.
- Inicie os nós restantes.
O diagrama a seguir ilustra nossa arquitetura para este exercício:
Etapa 1 - Configurar o novo cluster MariaDB
Instale o ClusterControl e implante um novo MariaDB Cluster. Vá para ClusterControl -> Deploy -> Deploy Database Cluster -> MySQL Galera e especifique as informações necessárias na caixa de diálogo de implantação:
Clique no botão Deploy e inicie a implantação. Como temos apenas um cluster no servidor antigo, o ID do cluster deve ser idêntico (ID do cluster:1) nesta nova instância.
Etapa 2 - Exportar e importar os arquivos de backup Depois que o cluster for implantado, teremos que importar os backups do servidor ClusterControl antigo para o novo. Primeiro, exporte o conteúdo de cmon.backup_records para despejar arquivos. Como o ID do cluster antigo e o novo são idênticos, basta modificar o arquivo de despejo com o novo endereço IP e importá-lo para o novo nó ClusterControl. Se o ID do cluster for diferente, será necessário alterar o valor “cid” de acordo dentro dos arquivos de despejo antes de importar para o CMON DB no novo nó. Além disso, é mais fácil manter o local de armazenamento de backup como no servidor antigo para que o novo ClusterControl possa localizar os arquivos de backup no novo servidor.
No servidor ClusterControl antigo, exporte a tabela backup_records para arquivos de despejo:
$ mysqldump -uroot -p --single-transaction --no-create-info cmon backup_records > backup_records.sqlEm seguida, execute a cópia remota dos arquivos de backup do servidor antigo para o novo servidor ClusterControl:
$ scp -r /root/backups 192.168.55.150:/root/
$ scp ~/backup_records.sql 192.168.55.150:~O próximo passo é modificar os arquivos de despejo para refletir o novo endereço IP do servidor ClusterControl. Não se esqueça de escapar do ponto no endereço IP:
$ sed -i "s/192\.168\.55\.170/192\.168\.55\.150/g" backup_records.sqlNo novo servidor ClusterControl, importe os arquivos de despejo:
$ mysql -uroot -p cmon < backup_records.sqlVerifique se a lista de backup está correta no novo servidor ClusterControl:
Como você pode ver, todas as ocorrências do endereço IP anterior (192.168.55.170) foram substituídas pelo novo endereço IP (192.168.55.150). Agora estamos prontos para realizar a restauração no novo servidor.
Etapa 3 - Realize a restauração
Executar a restauração por meio da interface do usuário do ClusterControl é uma etapa simples de apontar e clicar. Escolha qual backup restaurar e clique no botão “Restaurar”. Vamos restaurar o último backup incremental disponível (Backup:9). Clique no botão "Restaurar" logo abaixo do nome do backup e você verá a seguinte caixa de diálogo de pré-restauração:
Parece que o tamanho do backup é bem pequeno (165,6 kB). Isso realmente não importa porque o ClusterControl preparará todos os backups incrementais agrupados no Backup Set 6, que contém o Xtrabackup completo. Você também tem várias opções de pós-restauração:
- Restaurar backup em - Escolha o nó para restaurar o backup.
- Tmp Dir - O diretório será usado no servidor ClusterControl local como armazenamento temporário durante a preparação do backup. Ele deve ser tão grande quanto o diretório de dados estimado do MySQL.
- Bootstrap cluster a partir do nó restaurado - Como este é um novo cluster, vamos ativar isso para que o ClusterControl inicialize o cluster automaticamente após a restauração ser bem-sucedida.
- Faça uma cópia do datadir antes de restaurar o backup - Se os dados restaurados estiverem corrompidos ou não conforme o esperado, você terá um backup do diretório de dados MySQL anterior. Como este é um novo cluster, vamos ignorá-lo.
A restauração do Percona Xtrabackup fará com que o cluster seja interrompido. O ClusterControl irá:
- Parar todos os nós no cluster.
- Restaure o backup no nó selecionado.
- Inicialize o nó selecionado.
Para ver o progresso da restauração, vá para Activity -> Jobs -> Restore Backup e clique no botão “Full Job Details”. Você deve ver algo assim:
Uma coisa importante que você precisa fazer é monitorar a saída do log de erros do MySQL no nó de destino (192.168.55.151) durante o processo de restauração. Após a conclusão da restauração e durante o processo de bootstrap, você deverá ver as seguintes linhas começando a aparecer:
Version: '10.1.22-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 3306 MariaDB Server
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:51 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:52 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:53 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:54 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)
2017-04-07 18:03:55 140608191986432 [Warning] Access denied for user 'cmon'@'192.168.55.150' (using password: YES)Não entrar em pânico. Esse é um comportamento esperado porque esse conjunto de backup não armazena as credenciais de login do cmon da nova senha do cmon do ClusterControl. Ele restaurou/substituiu o antigo usuário cmon. O que você precisa fazer é conceder novamente o usuário cmon ao servidor executando a seguinte instrução neste nó de banco de dados:
GRANT ALL PRIVILEGES ON *.* to [email protected]'192.168.55.150' IDENTIFIED BY 'mynewCMONpassw0rd' WITH GRANT OPTION;
FLUSH PRIVILEGES;O ClusterControl seria capaz de se conectar ao nó bootstrap e determinar o nó e o estado de backup. Se tudo estiver OK, você deverá ver algo assim:
Neste ponto, o nó de destino é inicializado e em execução. Podemos iniciar os nós restantes em Nodes -> escolha node -> Start Node e marque a caixa de seleção “Perform an Initial Start”:
A restauração agora está concluída e você pode esperar que Performance -> DB Growth relate o tamanho atualizado de nosso conjunto de dados recém-restaurado:
Feliz restauração!
