MariaDB
 sql >> Base de Dados >  >> RDS >> MariaDB

Teste automatizado do processo de atualização para MySQL/MariaDB/Percona Server

As atualizações são sempre uma tarefa difícil e demorada. Primeiro, você deve testar seu aplicativo em um ambiente de teste, portanto, idealmente, você precisará clonar seu ambiente de produção atual para isso. Então, você precisa fazer um plano para realizar a atualização que, dependendo do negócio, pode ser com zero downtime (ou quase zero), ou até mesmo agendar uma janela de manutenção para ter certeza de que, se algo der errado, afetará tão pouco que possível.

Se você quiser fazer todas essas coisas manualmente, há uma grande chance de erro humano e o processo será lento. Neste blog, veremos como automatizar os testes para atualizar seus bancos de dados MySQL, MariaDB ou Percona Server usando o ClusterControl.

Tipo de atualizações

Existem dois tipos de upgrades:Upgrades Secundários e Upgrades Principais.

Atualizações menores

O primeiro, Minor Upgrade, é o upgrade mais comum e seguro e, na maioria dos casos, é realizado no local. Como nada é 100% seguro, você deve sempre ter backups e nós escravos de replicação, então caso algo dê errado com o upgrade e por algum motivo você não consiga reverter/rebaixar, você pode promover um nó escravo, e seus sistemas ainda podem trabalhar sem interrupção.

Você pode realizar esse tipo de atualização usando o ClusterControl. Para isso, vá para ClusterControl -> Selecione o Cluster -> Gerenciar -> Upgrades.

Em cada nó selecionado, o procedimento de atualização irá:

  • Parar nó

  • Nó de atualização

  • Iniciar nó

O nó mestre em uma topologia de replicação não será atualizado. Para atualizar o mestre, outro nó deve ser promovido primeiro para se tornar o novo mestre.

Grandes atualizações

Para Upgrades Principais, não é recomendado o upgrade in-loco, pois o risco de algo dar errado é muito alto para um ambiente de produção. Em vez disso, você pode clonar seu cluster de banco de dados atual e testar seu aplicativo lá e, ao terminar, pode recriá-lo ou até mesmo criar um novo cluster na nova versão e alternar o tráfego quando estiver pronto. Existem diferentes abordagens para essas atualizações. Você pode atualizar os nós um por um ou criar um cluster diferente replicando o tráfego do atual, também pode usar balanceadores de carga para melhorar a alta disponibilidade e mais opções. A melhor abordagem depende da tolerância de tempo de inatividade e do Objetivo de Tempo de Recuperação (RTO).

Você não pode realizar Atualizações Principais diretamente com o ClusterControl, porque, como mencionamos, você precisa testar tudo primeiro, para ter certeza de que a atualização é segura, mas você pode usar diferentes recursos do ClusterControl para fazer esta tarefa mais fácil. Então vamos ver alguns desses recursos.

Backups

Os backups são obrigatórios antes de qualquer atualização. Uma boa política de backup pode evitar grandes problemas para o negócio. Então, vamos ver como o ClusterControl pode automatizar isso.

Criando um backup

Vá para ClusterControl -> Selecione o Cluster -> Backup -> Criar Backup.


Você pode criar um novo backup ou configurar um backup agendado.


Você pode escolher diferentes métodos de backup, dependendo da tecnologia do banco de dados e, na mesma seção, pode escolher o servidor do qual deseja fazer o backup, onde deseja armazenar o backup e se você deseja fazer upload do backup para a nuvem (AWS, Azure ou Google Cloud) no mesmo trabalho.


Você também pode compactar e criptografar seu backup e especificar o período de retenção, entre outras opções.


Na seção de backup, você pode ver o andamento do backup e informações como método, tamanho, local e muito mais.

Implantando um ambiente de teste

Para isso, você não precisa criar tudo do zero. Em vez disso, você pode usar o ClusterControl para fazer isso de maneira manual ou automatizada.

Restaurar backup no host autônomo

Na seção Backup, você pode escolher a opção “Restaurar e verificar no host autônomo” para restaurar um backup em um nó separado.


Aqui você pode especificar se deseja que o ClusterControl instale o software no novo nó e desative o firewall ou o AppArmor/SELinux (dependendo do sistema operacional). Para isso, você precisa de um host dedicado (ou VM) que não faça parte do cluster.


Você pode manter o nó funcionando ou o ClusterControl pode encerrar o serviço de banco de dados até a próxima tarefa de restauração. Quando terminar, você verá o backup restaurado/verificado na lista de backups marcado com um visto.


Se você não quiser fazer esta tarefa manualmente, você pode agendar este processo usando o recurso Verificar backup, para repetir este trabalho periodicamente em um trabalho de backup. Veremos como fazer isso na próxima seção.

Verificação automática de backup do ClusterControl

Para automatizar esta tarefa, vá para ClusterControl -> Selecione seu Cluster -> Backup -> Criar Backup e escolha a opção Backup Agendado.


O recurso de verificação automática de backup só está disponível para backups agendados e o processo é o mesmo que descrevemos em uma seção anterior. Na segunda etapa, certifique-se de ter ativado a opção Verificar backup e preencha as informações necessárias.


Quando o trabalho estiver concluído, você poderá ver o ícone de verificação na seção ClusterControl Backup, o mesmo que você terá fazendo a verificação de forma manual, com a diferença de que você não precisa se preocupar com a tarefa de restauração. O ClusterControl restaurará o backup sempre automaticamente e você poderá testar seu aplicativo com os dados mais recentes.

Recuperação automática e failover

Com o recurso Autorecovery habilitado, em caso de falha, o ClusterControl irá promover o nó escravo mais avançado a mestre, além de notificá-lo sobre o problema. Ele também faz failover do restante dos nós escravos para replicar a partir do novo servidor mestre.

Se houver balanceadores de carga na topologia, o ClusterControl os reconfigurará para aplicar as alterações de topologia.

Você também pode executar um Failover manualmente, se necessário. Vá para ClusterControl -> Select the Cluster -> Nodes -> Selecione o Node a ser promovido -> Node Actions -> Promote Slave.

Dessa forma, se algo der errado durante a atualização, você poderá usar o ClusterControl para corrigi-lo o mais rápido possível.

Automatizando coisas com CLI ClusterControl

ClusterControl CLI, também conhecido como s9s, é uma ferramenta de linha de comando introduzida no ClusterControl versão 1.4.1 para interagir, controlar e gerenciar clusters de banco de dados usando o sistema ClusterControl. ClusterControl CLI abre uma porta para automação de cluster onde você pode facilmente integrá-lo com ferramentas de automação de implantação existentes como Ansible, Puppet, Chef, etc. Vamos ver agora alguns exemplos desta ferramenta.

Atualizar

$ s9s cluster --cluster-id=19 \
--check-pkg-upgrades \
--log
$ s9s cluster --cluster-id=19 \
--available-upgrades \
--nodes='10.10.10.146' \
--log \
--print-json
$ s9s cluster --cluster-id=19 \
--upgrade-cluster \
--nodes='10.10.10.146' \
--log

Criar backup

$ s9s backup --create \
--backup-method=mysqldump \
--cluster-id=2 \
--nodes=10.10.10.146:3306 \
--on-controller \
--backup-directory=/storage/backups
--log

Restaurar backup

$ s9s backup --restore \
--cluster-id=19 \
--backup-id=3 \
--wait

Verificar backups

$ s9s backup --verify \
--backup-id=3 \
--test-server=10.10.10.151 \
--cluster-id=19 \
--log

Promover Nó Escravo

$ s9s cluster --promote-slave \
--cluster-id=19 \
--nodes='10.10.10.146' \
--log

Conclusão

As atualizações são tarefas necessárias, mas demoradas. A implantação de um ambiente de teste sempre que você precisar atualizar pode ser um pesadelo, e é difícil mantê-lo atualizado sem nenhuma ferramenta de automatização.

O ClusterControl permite realizar pequenas atualizações ou até mesmo implantar o ambiente de teste para tornar a tarefa de atualização mais fácil e segura. Você também pode integrá-lo a diferentes ferramentas de automação, como Ansible, Puppet e muito mais.