Automatize a implantação do seu cluster MySQL ou Postgres a partir do backup

O ClusterControl 1.7.1 apresenta um novo recurso chamado Create Cluster from Backup, que permite implantar um novo cluster baseado em MySQL ou Postgres e restaurar dados nele a partir de um backup. Esta postagem de blog mostra como esse novo recurso funciona e como esse tipo de automação pode fornecer melhorias para suas operações de infraestrutura.

Apresentação:Criar cluster a partir do backup

O gerenciamento de backup é o recurso mais amado por nossos usuários, e acabamos de levá-lo para o próximo nível. Essa nova funcionalidade parece simples - o ClusterControl 1.7.1 é capaz de implantar um novo cluster a partir de um backup existente. No entanto, há vários procedimentos e verificações envolvidos para implantar um cluster de nível de produção diretamente de um backup. A restauração em si vem com seus próprios desafios, como:

Consequências da restauração total ou parcial
Backup básico e sua ordenação de backups incrementais (para backup incremental)
Descriptografia de backup (se criptografado)
Opções da ferramenta de restauração
Descompactação (se compactada)
Backup de streaming da origem para o servidor de destino
Utilização do espaço em disco durante e após a restauração
Relatório de progresso da restauração

Combine o acima com a complexidade e repetitividade das tarefas de implantação de cluster de banco de dados, você pode economizar tempo e reduzir o risco na execução de procedimentos propensos a erros. A parte mais difícil da perspectiva do usuário é escolher de qual backup restaurar. O ClusterControl cuidará de todo o trabalho pesado nos bastidores e relatará o resultado final assim que terminar.

Os passos são basicamente simples:

Configure o SSH sem senha do nó ClusterControl para os novos servidores.
Escolha um backup lógico da lista de backups ou crie um em Backups -> Criar backup .
Clique em Restaurar -> Criar cluster do backup e siga o assistente de implantação.

Esse recurso foi desenvolvido especificamente para MySQL Galera Cluster e PostgreSQL no momento. Aqui está o que você veria na interface do usuário depois de clicar em "Restaurar" em um backup existente:

A opção inferior é o que estamos procurando. Em seguida, é a caixa de diálogo de resumo no backup escolhido antes da configuração de implantação:

Em seguida, o mesmo assistente de implantação de cluster de banco de dados para o respectivo cluster (MySQL Galera Cluster ou PostgreSQL) será mostrado para configurar um novo cluster:

Observe que você deve especificar o mesmo nome de usuário e senha de administrador/raiz do banco de dados que você tem no backup. Caso contrário, a implantação falharia no meio do caminho ao iniciar o primeiro nó. Em geral, os procedimentos de restauração e implantação acontecerão na seguinte ordem:

Instale os softwares e dependências necessários em todos os nós do banco de dados.
Inicie o primeiro nó.
Transmita e restaure o backup no primeiro nó (com sinalizador de reinicialização automática).
Configure e adicione o restante dos nós.

Um novo cluster de banco de dados será listado no painel do cluster ClusterControl assim que o trabalho for concluído.

O que você pode ganhar com isso?

Há várias coisas que você pode se beneficiar desse recurso, conforme explicado nas seções a seguir.

Teste seu conjunto de dados em várias condições

Às vezes, você pode estar se perguntando se a nova versão do banco de dados funcionaria ou funcionaria para sua carga de trabalho de banco de dados e testá-la é a única maneira de saber. É aqui que esse recurso é útil. Ele permite que você execute testes e benchmark em muitas variáveis envolvidas que afetariam a estabilidade ou o desempenho do banco de dados, por exemplo, o hardware subjacente, a versão do software, o fornecedor e as cargas de trabalho do banco de dados ou do aplicativo.

Para um exemplo simples, há uma grande melhoria na execução de DDL entre o MySQL 5.6 e o MySQL 5.7. A seguinte operação DROP em uma tabela de 10 milhões de linhas prova tudo:

mysql-5.7> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (1 min 58.12 sec)

mysql-5.6> ALTER TABLE sbtest1 DROP COLUMN xx;
Query OK, 0 rows affected (2 min 23.74 sec)

Ter outro cluster para comparar, na verdade, nos permite medir a melhoria e justificar uma migração.

Migração de banco de dados com backup lógico

Backup lógico como mysqldump e pg_dumpall é a maneira mais segura de atualizar, fazer downgrade ou migrar seus dados de uma versão ou fornecedor para outro. Todos os backups lógicos podem ser usados para realizar a migração do banco de dados. As etapas de atualização do banco de dados são basicamente simples:

Crie (ou agende) um backup lógico - mysqldump para MySQL ou pg_dumpall para PostgreSQL
Configure o SSH sem senha do nó ClusterControl para os novos servidores.
Escolha um backup lógico criado na lista de backups.
Clique em Restaurar -> Criar cluster do backup e siga o assistente de implantação.
Verifique a restauração de dados no novo cluster.
Aponte seu aplicativo para o novo cluster.

Tempo total de recuperação de cluster mais rápido

Imagine uma falha catastrófica que impede a execução do cluster, como, por exemplo, uma falha de armazenamento centralizado que afetou todas as máquinas virtuais conectadas a ele, você pode obter um cluster substituto quase imediatamente (desde que os arquivos de backup sejam armazenados fora dos nós do banco de dados com falha , afirmando o óbvio). Este recurso pode ser automatizado via cliente s9s, onde você pode acionar um trabalho através da interface de linha de comando, por exemplo:

$ s9s cluster \
--create \
--cluster-type=postgresql \
--nodes="192.168.0.101?master;192.168.0.102?slave;192.168.0.103?slave" \
--provider-version=11 \
--db-admin=postgres \
--db-admin-passwd='s3cr3tP455' \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--cluster-name="PostgreSQL 9.6 - Test"
--backup-id=214 \
--log

Uma coisa a observar ao usar esse recurso é usar o mesmo nome de usuário e senha de administrador que está armazenado no backup. Além disso, o SSH sem senha para todos os nós do banco de dados deve ser configurado antecipadamente. Caso contrário, se preferir configurá-lo de forma interativa, basta usar a interface web UI.

Escalonar por meio de replicação assíncrona

Para o MySQL Galera Cluster, o cluster recém-criado tem a possibilidade de ser dimensionado via replicação assíncrona do MySQL. Digamos que já restauramos um novo cluster no escritório com base no backup mais recente do cluster de produção no data center e gostaríamos que o cluster do escritório continuasse a replicar do cluster de produção, conforme ilustrado no diagrama a seguir:

Você pode então configurar o link de replicação assíncrona usando a seguinte maneira:

Escolha um nó na produção e habilite o log binário (se desabilitado). Vá para Nodes -> escolha um node -> Node Actions -> Enable Binary Logging.
Habilite o log binário em todos os nós do cluster de escritório. Esta ação requer uma reinicialização contínua que será executada automaticamente se você escolher "Sim" no menu suspenso "Nó de reinicialização automática":

Caso contrário, você pode executar essa operação sem tempo de inatividade usando Gerenciar -> Atualizar -> Reinicialização sem interrupção (ou reiniciar manualmente um nó por vez).
Crie um usuário de replicação no cluster de produção usando Gerenciar -> Esquemas e usuários -> Usuários -> Criar novo usuário:

Em seguida, escolha um nó para replicar para o nó mestre no cluster de produção e configure o link de replicação:

mysql> CHANGE MASTER master_host = 'prod-mysql1', master_user = 'slave', master_password = 'slavepassw0rd', master_auto_position = 1;
mysql> START SLAVE;

Verifique se a replicação está em execução:
```
mysql> SHOW SLAVE STATUS\G
```
Certifique-se de que Slave_IO_Thread e Slave_SQL_thread estejam relatando 'Sim'. O cluster do escritório deve começar a acompanhar o nó mestre se estiver atrasado.

Por enquanto é isso pessoal!