No centro do ClusterControl está sua automação, assim como garantir que seus dados sejam copiados com segurança e estejam prontos para restauração sempre que algo der errado. Ter uma estratégia de backup eficaz e um plano de recuperação de desastres é a chave para o sucesso de qualquer aplicativo ou ambiente.
Em nossa versão mais recente, ClusterControl 1.5, introduzimos vários aprimoramentos para fazer backup de sistemas baseados em MySQL e MariaDB.
Uma das principais melhorias é a capacidade de fazer backup do ClusterControl para o provedor de nuvem de sua escolha. Provedores de nuvem, como Google Cloud Services e Amazon S3, oferecem armazenamento praticamente ilimitado, reduzindo as necessidades de espaço local. Isso permite que você retenha seus arquivos de backup por mais tempo, pelo tempo que desejar e não se preocupe com o espaço em disco local.
Vamos explorar todos os novos recursos de backup do ClusterControl 1.5...
Redesign do Assistente de Backup/Restauração
Em primeiro lugar, você notará que os assistentes de backup e restauração foram renovados para melhorar a experiência do usuário. Ele agora será carregado como um menu lateral à direita da tela:
A lista de backup também está recebendo um pequeno ajuste onde os detalhes do backup são exibidos quando você clica no backup específico:
Você poderá visualizar o local do backup e quais bancos de dados estão dentro do backup. Há também opções para restaurar o backup ou carregá-lo na nuvem.
Backup compatível com PITR
O ClusterControl executa o backup padrão do mysqldump com esquema e despejos de dados separados. Isso facilita a restauração de backups parciais. No entanto, ele quebra a consistência do backup (o esquema e os dados são despejados em duas sessões separadas), portanto, não pode ser usado para provisionar um escravo ou uma recuperação pontual.
Um backup compatível com mysqldump PITR contém um único arquivo de despejo, com informações do GTID, arquivo binlog e posição. Assim, apenas o nó do banco de dados que produz o log binário terá disponível a opção "PITR compatível", conforme destacado na captura de tela abaixo:
Quando a opção compatível com PITR é alternada, os campos do banco de dados e da tabela ficam acinzentados, pois o ClusterControl sempre fará o backup de todos os bancos de dados, eventos, gatilhos e rotinas do servidor MySQL de destino.
As seguintes linhas aparecerão nas primeiras ~50 linhas do arquivo de despejo concluído:
$ head -50 mysqldump_2017-11-07_072250_complete.sql
...
-- GTID state at the beginning of the backup
--
SET @@GLOBAL.GTID_PURGED='20dc5247-4a98-ee18-73af-5c79373388ee:1-1681';
--
-- Position to start replication or point-in-time recovery from
--
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=2457790;
...As informações podem ser usadas para construir escravos a partir de backup, ou executar recuperação pontual junto com logs binários, onde você pode iniciar a recuperação do MASTER_LOG_FILE e MASTER_LOG_POS relatados no arquivo de despejo usando o utilitário "mysqlbinlog". Observe que não é feito backup de logs binários pelo ClusterControl.
Construir escravos a partir do backup Outro recurso é a capacidade de construir um escravo diretamente de um backup compatível com PITR, em vez de fazê-lo a partir de um mestre escolhido. Esta é uma grande vantagem, pois descarrega o servidor mestre. Esta opção pode ser usada com MySQL Replication ou Galera Cluster. Um backup existente pode ser usado para reconstruir um escravo de replicação existente ou adicionar um novo escravo de replicação durante a fase de preparo, conforme mostrado na captura de tela a seguir:
Assim que o teste for concluído, o escravo se conectará ao mestre escolhido e começará a recuperar o atraso. Anteriormente, o ClusterControl realizava um backup de streaming diretamente do mestre escolhido usando o Percona Xtrabackup. Isso pode afetar o desempenho do mestre ao dimensionar um grande conjunto de dados, apesar de a operação não ser bloqueante no mestre. Com a nova opção, se o backup for armazenado no ClusterControl, apenas esses hosts (ClusterControl + o escravo) estarão ocupados ao staging os dados no escravo.
Backup na nuvem
Os backups agora podem ser carregados automaticamente na nuvem. Isso requer a instalação de um módulo ClusterControl, chamado clustercontrol-cloud (módulo de integração na nuvem) e clustercontrol-clud (Cloud download/upload CLI) que estão disponíveis na v1.5 e posterior. As instruções de atualização foram incluídas nesses pacotes e elas vêm sem nenhuma configuração extra. No momento, as plataformas de nuvem suportadas são Amazon Web Services e Google Cloud Platform. As credenciais de nuvem são configuradas em ClusterControl -> Configurações -> Integrações -> Provedores de nuvem.
Ao criar ou agendar um backup, você deverá ver as seguintes opções adicionais quando "Fazer upload de backup para a nuvem" for alternado:
O recurso permite um upload único ou agendar backups para serem carregados após a conclusão (Amazon S3 ou Google Cloud Storage). Você pode então baixar e restaurar os backups conforme necessário.
Compressão personalizada para mysqldump
Esse recurso foi, de fato, introduzido pela primeira vez com o ClusterControl v1.4.2 após seu lançamento. Adicionamos um nível de compactação de backup baseado em gzip. Anteriormente, o ClusterControl usava a compactação de backup padrão (nível 6) se o destino do backup estivesse no nó do controlador. A compactação mais baixa (nível 1 - mais rápida, menos compactação) era usada se o destino de backup estivesse no próprio host do banco de dados, para garantir o mínimo impacto no banco de dados durante a operação de compactação.
Nesta versão, aprimoramos o aspecto de compactação e agora você pode personalizar o nível de compactação, independentemente do destino do backup. Ao atualizar sua instância do ClusterControl, todos os backups agendados serão convertidos automaticamente para usar o nível 6, a menos que você os edite explicitamente na v1.5.
A compactação de backup é vital quando seu conjunto de dados é grande, combinado com uma política de retenção de backup longa, enquanto o espaço de armazenamento é limitado. O Mysqldump, que é baseado em texto, pode se beneficiar da compactação com economia de até 60% do espaço em disco do tamanho do arquivo original. Em algumas ocasiões, a taxa de compressão mais alta é a melhor opção, embora tenha o preço de uma descompressão mais longa ao restaurar.
Recurso de bônus:verificação automática de backup
Como dizem os administradores de sistema antigos - Um backup não é um backup se não for restaurável. A verificação de backup é algo que geralmente é negligenciado por muitos. Alguns administradores de sistemas desenvolveram rotinas internas para isso, geralmente mais manuais do que automatizadas. Automatizá-lo é difícil, principalmente devido à complexidade da operação como um todo - começando pelo provisionamento do host, instalação e preparação do MySQL, transferência de arquivos de backup, descompactação, operação de restauração, procedimentos de verificação e, finalmente, limpeza do sistema após o processo. Todos esses aborrecimentos fazem com que as pessoas negligenciem um aspecto tão importante de um backup confiável. Em geral, um teste de restauração de backup deve ser feito pelo menos uma vez por mês, ou em caso de alterações significativas no tamanho dos dados ou na estrutura do banco de dados. Encontre uma agenda que funcione para você e formalize-a com um evento agendado.
O ClusterControl pode automatizar a verificação de backup realizando a restauração em um novo host, sem comprometer nenhum dos procedimentos de verificação mencionados acima. Isso pode ser feito após algum atraso ou logo após a conclusão do backup. Ele relatará o status do backup com base no código de saída da operação de restauração, executará o desligamento automático se o backup for verificado ou simplesmente permitirá que o host restaurado seja executado para que você execute verificações manuais adicionais nos dados.
Ao criar ou agendar um backup, você terá opções adicionais se "Verificar backup" estiver alternado:
Se "Instalar software de banco de dados" estiver ativado, o ClusterControl removerá qualquer instalação MySQL existente no host de destino e reinstalará o software de banco de dados com a mesma versão do servidor MySQL existente. Caso contrário, se você tiver uma configuração específica para o host restaurado, poderá ignorar esta opção. As demais opções são autoexplicativas.
Recurso de bônus:não esqueça o PostgreSQL
Além de toda essa grande funcionalidade para MySQL e MariaDB, o ClusterControl 1.5 agora também fornece ao PostgreSQL um método de backup adicional (pg_basebackup) que pode ser usado para backups binários online. Os backups feitos com pg_basebackup podem ser usados posteriormente para recuperação pontual e como ponto de partida para um envio de log ou servidores em espera de replicação de streaming.
Por enquanto é isso. Experimente o ClusterControl v1.5, experimente os novos recursos e diga-nos o que pensa.
