Teste automatizado do processo de atualização para PXC/MariaDB Galera Cluster

Atualizar seu banco de dados para clusters baseados em Galera, como Percona XtraDB Cluster (PXC) ou MariaDB Galera Cluster, pode ser um desafio, especialmente para um ambiente baseado em produção. Você não pode perder o estado de sua alta disponibilidade e colocá-lo em risco.

Um procedimento de atualização deve ser bem documentado e, idealmente, documentação, testes rigorosos e benchmarking devem ser feitos antes das atualizações. Mais importante, a segurança e as melhorias também devem ser identificadas com base no registro de alterações da atualização da versão do banco de dados.

Com todas as preocupações, a automação ajuda a obter um processo de atualização mais eficiente e ajuda a evitar erros humanos e melhora o RTO.

Como gerenciar o processo de atualização do cluster PXC/MariaDB Galera 

A atualização do seu PXC/MariaDB Galera Cluster requer documentação adequada e fluxo de processo que lista as coisas a serem feitas e o que fazer caso as coisas dêem errado. Isso significa que um Plano de Continuidade de Negócios que também deve cobrir seu Plano de Recuperação de Desastres deve ser estabelecido. Você não pode perder seu negócio em caso de problemas.

O procedimento usual é começar primeiro com o ambiente de teste. O ambiente de teste deve ter exatamente as mesmas configurações e configurações do seu ambiente de produção. Você não pode prosseguir diretamente com a atualização do ambiente de produção, pois não tem certeza de qual efeito e impacto ocorrerá se as coisas não estiverem de acordo com o plano.

Trabalhar com um ambiente de produção é altamente sensível, portanto, na maioria dos casos, um tempo de inatividade e uma janela de manutenção estão sempre presentes para evitar um impacto drástico.

Existem dois tipos de atualização para PCX ou MariaDB Galera Cluster que você precisa conhecer. Estas são a atualização de versão principal e a atualização de versão secundária ou muitas vezes referida como atualização in-loco. Uma atualização in-loco é onde você pode atualizar sua versão de banco de dados para sua versão secundária mais recente usando os mesmos dados binários de seu banco de dados. Não haverá alterações físicas nos dados em si, mas apenas no binário do banco de dados ou nos pacotes de software subjacentes.

Atualizando o cluster PCX ou MariaDB Galera para uma versão principal

A atualização para uma versão principal pode ser um desafio, especialmente para um ambiente de produção. Envolve um tipo complexo de configuração de banco de dados e recursos integrados especiais de PXC ou MariaDB Galera Cluster. Dados espaço-temporais, com registro de data e hora, dados de máquina ou quaisquer dados multifacetados são muito conservadores e sensíveis a atualizações. Você não pode aplicar uma atualização in-loco para este processo porque muitas alterações importantes teriam sido feitas. A menos que você tenha dados muito pequenos ou dados consistindo em idempotentes ou dados que possam ser gerados facilmente, pode ser seguro fazer isso, desde que você saiba que o impacto não afetará seus dados.

Se o volume de dados for grande, é melhor automatizar o processo de atualização. No entanto, pode não ser uma solução ideal automatizar toda a sequência no processo de atualização, pois podem ocorrer problemas inesperados durante a fase principal de atualização. É melhor automatizar etapas e processos repetitivos com resultados conhecidos em uma atualização importante. A qualquer momento, é necessário um recurso para avaliar se o processo de automação é seguro para evitar interrupções no processo de atualização. O teste automatizado após a atualização é igualmente importante e deve ser incluído como parte do processo de pós-atualização.

Atualizando o cluster PCX ou MariaDB Galera para uma versão secundária

Uma atualização de versão menor conhecida como atualização in-loco geralmente é uma abordagem mais segura para realizar um processo de atualização. Isso ocorre porque as alterações mais comuns para esta versão são patches ou melhorias de segurança e exploração, bugs (geralmente graves) ou problemas de compatibilidade que exigem patches, especialmente se o hardware ou sistema operacional atual teve alterações aplicadas que também podem fazer com que o banco de dados não funcionar corretamente. Embora o impacto geralmente possa ser recuperável com um efeito mínimo, ainda é obrigatório que você veja e leia o log de alterações que foi enviado para a atualização de versão secundária específica.

Implantar o trabalho para realizar o processo de atualização é um exemplo ideal de automação. O fluxo usual é muito repetitivo e não causa danos ao seu PXC ou MariaDB Galera Cluster existente. O que mais importa é que, após a atualização, os testes automatizados devem prosseguir para determinar se a instalação, configuração, eficiência e funcionalidade não foram interrompidas.

Evite os fiascos! Esteja pronto, automatize!

Um cliente nosso nos procurou pedindo ajuda porque, após a pequena atualização do banco de dados, um recurso que eles estão usando no banco de dados não está funcionando corretamente. Eles pediram etapas e processos sobre como fazer o downgrade e quão seguro será. Seus clientes estavam reclamando que seu aplicativo não está funcionando totalmente, generalizando que não é útil.

Mesmo para uma falha tão pequena, um cliente irritado pode dar uma má observação ao seu produto. A lição aprendida com esse cenário é que a falha no teste após uma atualização leva à suposição de que todas as funções em um banco de dados estão funcionando conforme o esperado.

Suponha que você tenha planos para automatizar o processo de atualização, então observe que o tipo de processo de automação varia de acordo com o tipo de atualização que você precisa fazer. Como mencionado anteriormente, uma atualização principal versus uma atualização secundária tem diferentes abordagens distintas. Portanto, sua configuração de autômato pode não se aplicar a ambas as atualizações de software de banco de dados.

Automatizando após o processo de atualização

Neste ponto, espera-se que seu processo de atualização seja feito, idealmente, por meio de automação. Agora que seu banco de dados está pronto para receber conexões de clientes, ele deve seguir com uma fase de testes rigorosa.

Executar mysql_upgrade

É muito importante e extremamente recomendado executar mysql_upgrade assim que o processo de atualização estiver concluído. mysql_upgrade procura incompatibilidades com o servidor MySQL atualizado fazendo o seguinte:

• Ele atualiza as tabelas do sistema no esquema mysql para que você possa aproveitar novos privilégios ou recursos que podem foi adicionado.
  

• Ele atualiza o esquema de desempenho e o esquema sys.
  

• Examina esquemas de usuário.
  

O mysql_upgrade determina se uma tabela tem problemas como incompatibilidades devido a alterações na versão mais recente após a atualização e tenta resolvê-lo reparando a tabela. Caso contrário, se falhar, seu teste de automação deverá falhar e não deverá prosseguir para outra coisa. Tem que ser investigado primeiro e fazer um reparo manual.

Verificar logs de erros

Uma vez que o mysql_upgrade é feito, você precisa verificar e verificar os erros que ocorreram. Você pode colocar isso em um script e verificar se há rótulos de "erro" ou "aviso" nos logs de erro. É muito importante determinar se existe tal. Seu teste automatizado deve ter a capacidade de capturar armadilhas de erro ou pode esperar que uma entrada do usuário continue se o erro for mínimo ou esperado, caso contrário, pare o processo de atualização.

Faça um teste de unidade

Um ambiente de banco de dados TDD (Test Driven Development) é uma abordagem de desenvolvimento de software onde há uma série de casos de teste a serem validados e determinar se a validação é verdadeira (passa) ou falsa (reprova). Algo como o que temos na captura de tela abaixo:

Imagem cortesia de guru99.com

Este é um tipo de teste de unidade que ajuda a evitar bugs indesejados ou erros lógicos em seu aplicativo e em seu banco de dados. Lembre-se, se houver dados inválidos armazenados no banco de dados, isso prejudicaria todas as análises e transações de negócios, especialmente se envolver cálculos financeiros complexos ou equações matemáticas.

Se você perguntar, é realmente necessário realizar um teste de unidade após a atualização? Claro que é! Você não precisa necessariamente executar isso no ambiente de produção. Durante as fases de teste, ou seja, atualizando primeiro seu QAs, ambiente de desenvolvimento/preparação, ele deve ser aplicado nessa área. Os dados devem ser uma cópia exata pelo menos ou quase igual ao seu ambiente de produção. Seu objetivo aqui é evitar resultados indesejados e resultados lógicos definitivamente errados. Você tem que cuidar bem de seus dados, é claro, e determinar se os resultados passam no teste de validação.

Se você pretende rodar com sua produção, então faça. No entanto, não seja tão rígido quanto sua fase de teste aplicada no ambiente de controle de qualidade, desenvolvimento ou preparação. É porque você precisa planejar seu tempo com base na janela de manutenção disponível e evitar atrasos e RTO mais longos.

Na minha experiência, durante a fase de atualização, os clientes selecionam uma abordagem mais rápida que será importante para determinar se esse recurso fornece o resultado correto. Além disso, você pode ter um script para automatizar o teste de um conjunto de funções lógicas de negócios ou procedimentos armazenados, pois ajuda a armazenar em cache as consultas e tornar seu banco de dados quente.

Ao se preparar para o Teste Unitário do seu banco de dados, evite reinventar a roda. Em vez disso, dê uma olhada nas ferramentas disponíveis que você pode escolher se for bom para seus requisitos e necessidades. Confira Selenium, ou confira este blog.

Verificar a identidade das consultas

A ferramenta mais comum que você pode usar é o pt-upgrade do Percona. Ele verifica se os resultados da consulta são idênticos em servidores diferentes. Ele executa consultas com base nos logs fornecidos e na conexão fornecida (ou chamada de DSN), depois compara os resultados e relata quaisquer diferenças significativas. Ele oferece mais do que isso como suas opções para coletar ou analisar as consultas, como por meio do tcpdump, por exemplo.

Usar o pt-upgrade é fácil. Por exemplo, você pode executar com o seguinte comando:

## Comparing via slow log for the given hosts
pt-upgrade h=host1 h=host2 slow.log

## or use fingerprints, useful for debugging purposes
pt-upgrade --fingerprints --run-time=1h mysqld-slow.log h=127.0.0.1,P=5091 h=127.0.0.1,P=5517

## or with tcpdump,
tcpdump -i eth0 port 3306 -s 65535  -x -n -q -tttt     \
  | pt-query-digest --type tcpdump --no-report --print \
  | pt-upgrade h=host1 h=host2

É uma boa prática que uma vez que uma atualização, especialmente uma atualização de versão principal tenha sido realizada, pt-upgrade seja usado para prosseguir e realizar a análise de consulta identificando diferenças com base nos resultados. É uma boa prática fazer isso durante a fase de teste ao fazê-lo em seu QAs ou ambiente de teste e desenvolvimento para que você possa decidir se é mais seguro continuar. Você pode adicioná-lo à sua ferramenta de automação e executá-lo como um manual quando estiver pronto para cumprir seu dever.

Como automatizar o processo de teste?

Em nossos blogs anteriores, apresentamos diferentes maneiras de automatizar seus bancos de dados. As ferramentas mais comuns que estão em voga são essas ferramentas de software de implantação IaC (Infrastructure as Code). Você pode usar Puppet, Chef, SaltStack ou Ansible para fazer o trabalho.

Minha preferência sempre foi o Ansible para realizar meus testes automatizados, ele me permite criar playbooks por sua função. É claro que não posso criar um autômato completo que fará todas as coisas porque a situação e o ambiente variam. Com base nos tipos de atualização fornecidos anteriormente (atualização principal versus atualização secundária), você deve diferenciar seu processo. Mesmo que seja apenas uma atualização in-loco, você ainda precisa ter certeza de que seus playbooks realizarão o trabalho correto.

ClusterControl é seu amigo de automação de banco de dados!

ClusterControl é uma boa opção para realizar testes básicos e automatizados. ClusterControl não é uma estrutura para teste; não é uma ferramenta para fornecer testes de unidade. No entanto, é uma ferramenta de gerenciamento e monitoramento de banco de dados que incorpora muitas implantações automatizadas com base nos gatilhos solicitados pelo usuário ou administrador do software.

O ClusterControl oferece atualizações de versão secundárias, o que proporciona conveniência aos DBAs ao realizar atualizações. Ele faz mysql_upgrade em tempo real também. Portanto, você não precisa executá-lo manualmente. O ClusterControl também detecta novas versões a serem atualizadas e recomenda as próximas etapas a serem executadas. Em caso de falha, a atualização não prosseguirá.

Aqui está um exemplo da tarefa de atualização secundária:

Se você olhar com atenção, o mysql_upgrade é executado com sucesso. Embora não recomende e faça uma atualização automática do mestre, é porque não é a abordagem correta a seguir. Nesse caso, você deve promover o novo escravo e, em seguida, rebaixar o mestre como escravo para realizar a atualização.

Conclusão