Como fazer backup e restaurar o ClusterControl

• ID do cluster 1:3 nós Galera (PXC) + 1 HAProxy + 1 ProxySQL (5 nós)
• ID do cluster 2:1 MySQL master + 2 MySQL slaves + 1 ProxySQL (4 nós)

Introdução

Fazendo backup do ClusterControl

$ s9s backup \
--save-controller \
--backup-directory=$HOME/ccbackup \
--output-file=controller.tar.gz \
--log

1. Recupere a configuração do controlador e exporte-a para JSON
2. Exportar banco de dados CMON como arquivo de despejo MySQL
3. Para cada cluster de banco de dados:
   1. Recupere a configuração do cluster e exporte-a para JSON

Restaurando o ClusterControl para um novo ClusterControl Server

$ scp $HOME/ccbackup/controller.tar.gz 192.168.0.190:~

$ ssh-copy-id 192.168.0.11 #proxysql cluster 1
$ ssh-copy-id 192.168.0.12 #proxysql cluster 1
$ ssh-copy-id 192.168.0.21 #pxc cluster 1
$ ssh-copy-id 192.168.0.22 #pxc cluster 1
$ ssh-copy-id 192.168.0.23 #pxc cluster 1
$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2

$ s9s backup \
--restore-controller \
--input-file=$HOME/controller.tar.gz \
--debug \
--log

$ cat /etc/cmon.d/cmon_*.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=8fgkzdW8gAm2pL4L
cluster_id=2
rpc_key=tAnvKME53N1n8vCC

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

por uma senha MySQL cmon idêntica à do valor mysql_password dentro de /etc/cmon.cnf. Repita a mesma etapa no segundo cluster, replicação do MySQL, mas execute-a apenas uma vez no nó mestre.

Depois que o privilégio estiver configurado, você verá que a lista de clusters está em verde, semelhante à antiga:

Vale ressaltar que, por padrão, o ClusterControl desabilitará a recuperação automática do cluster (como você pode ver o ícone vermelho ao lado da palavra 'Cluster') para evitar a condição de corrida com outra instância do ClusterControl. É recomendável habilitar esse recurso (clicando no ícone verde) assim que o servidor antigo for desativado.

Nossa migração está concluída. Todas as configurações e configurações do servidor antigo são preservadas e transferidas para o novo servidor.

Migrando o gerenciamento de um cluster para outro servidor ClusterControl

Fazendo backup das informações do cluster

Trata-se de fazer backup de metadados e informações do cluster para que possamos transferi-los para outro servidor ClusterControl, também conhecido como backup parcial. Caso contrário, temos que executar "Importar Servidor/Cluster Existente" para reimportá-los para o novo ClusterControl, o que significa que você perderia os dados de monitoramento do servidor antigo. Se você tiver balanceadores de carga ou instâncias escravas assíncronas, isso deverá ser importado assim que o cluster for importado, um nó por vez. Portanto, é um pouco incômodo se você tiver um conjunto completo de configuração de produção.

O exercício de migração do "gerente" do cluster é ilustrado no diagrama a seguir:

Basicamente, queremos migrar nossa Replicação MySQL (ID do cluster:2) para ser gerenciada por outra instância do ClusterControl. Vamos usar as opções --save-cluster-info e --restore-cluster-info para este. A opção --save-cluster-info exportará as informações de cluster correspondentes para serem salvas em outro lugar. Vamos exportar nosso MySQL Replication Cluster (ID do cluster:2). No servidor ClusterControl atual, faça:

$ s9s backup \
--save-cluster-info \
--cluster-id=2 \
--backup-directory=$HOME/ccbackup \
--output-file=cc-replication-2.tar.gz \
--log

Você verá várias novas linhas impressas no terminal, indicando que o trabalho de backup está sendo executado (a saída também pode ser acessada via ClusterControl -> Activity -> Jobs ):

Se você observar os logs de trabalho com atenção, perceberá que o trabalho estava tentando exportar todas as informações e metadados relacionados para o ID de cluster 2. A saída é armazenada como um arquivo compactado e localizada no caminho que especificamos usando --backup -sinalizador de diretório. Se este sinalizador for ignorado, o ClusterControl salvará a saída no diretório de backup padrão, que é o diretório inicial do usuário SSH, em $HOME/backups.

Restaurando informações do cluster

As etapas explicadas aqui são semelhantes às etapas de restauração do backup completo do ClusterControl. Transfira o backup do servidor atual para o outro servidor ClusterControl:

$ scp $HOME/ccbackup/cc-replication-2.tar.gz 192.168.0.190:~

Antes de realizar a restauração, precisamos configurar o SSH sem senha para todos os nós do novo servidor ClusterControl:

$ ssh-copy-id 192.168.0.30 #proxysql cluster 2
$ ssh-copy-id 192.168.0.31 #mysql cluster 2
$ ssh-copy-id 192.168.0.32 #mysql cluster 2
$ ssh-copy-id 192.168.0.33 #mysql cluster 2
$ ssh-copy-id 192.168.0.19 #prometheus cluster 2

Em seguida, no novo servidor, execute a restauração das informações do cluster para nossa Replicação MySQL:

$ s9s backup \
--restore-cluster-info \
--input-file=$HOME/cc-replication-2.tar.gz \
--log

Você pode verificar o progresso em Atividade -> Trabalhos -> Restaurar cluster :

Se você observar atentamente as mensagens de trabalho, poderá ver que o ClusterControl reatribui automaticamente o ID do cluster a 1 nesta nova instância (era o ID do cluster 2 na instância antiga).

Em seguida, sincronize o cluster na interface do usuário acessando Configurações globais -> Registros de cluster -> Sincronizar cluster . Se você voltar ao painel principal do ClusterControl, verá o seguinte:

O erro significa que a nova IU do ClusterControl não consegue recuperar os dados de monitoramento e gerenciamento devido ao token de API RPC incorreto. Só precisamos atualizá-lo de acordo. Em primeiro lugar, recupere o valor rpc_key para nosso ID de cluster 1:

$ cat /etc/cmon.d/cmon_1.cnf | egrep 'cluster_id|rpc_key'
cluster_id=1
rpc_key=tAnvKME53N1n8vCC

Na interface do usuário, clique no link "aqui" na linha "Alterar o token da API RPC aqui". Irá aparecer a seguinte caixa de diálogo:

Cole o respectivo valor rpc_key no campo de texto e clique em Salvar. Aguarde um momento e a lista de clusters deve ser atualizada automaticamente.

A última etapa é corrigir os privilégios de usuário do MySQL cmon para as novas alterações de endereço IP do ClusterControl, 192.168.0.190. Faça login no nó mestre (192.168.0.31) e execute a seguinte instrução:

$ mysql -uroot -p -e 'GRANT ALL PRIVILEGES ON *.* TO [email protected]"192.168.0.190" IDENTIFIED BY "<password>" WITH GRANT OPTION';

** Substitua por uma senha MySQL cmon idêntica à do valor mysql_password dentro de /etc/cmon.cnf.

Você também pode revogar os privilégios do usuário antigo (revogar não excluirá o usuário) ou simplesmente descartar o usuário antigo:

$ mysql -uroot -p -e 'DROP USER [email protected]"192.168.0.19"'

Depois que o privilégio estiver configurado, você verá que tudo está verde:

Neste ponto, nossa arquitetura está mais ou menos assim:

Nosso exercício de migração está concluído.

Considerações finais

Agora é possível realizar backups completos e parciais de suas instâncias ClusterControl e dos clusters que elas gerenciam, permitindo que você as mova livremente entre hosts com pouco esforço. Sugestões e comentários são bem-vindos.