O teste é uma tarefa demorada, mas é uma necessidade antes de qualquer processo de atualização em qualquer tecnologia. Dependendo do tipo de atualização, pode ser mais difícil ou mais fácil, mas é sempre necessário se você quiser garantir que seus dados estejam seguros. Existem diferentes abordagens para atualização, dependendo do negócio e da tolerância ao tempo de inatividade. Por exemplo, o processo pode estar testando seu aplicativo em um ambiente separado com a nova versão, portanto, você precisará criar um novo cluster para isso. Outra opção é clonar seu ambiente de produção atual e atualizá-lo, o que pode ser útil, pois você pode emular todo o processo de atualização e evitar surpresas no futuro.
Fazendo todo esse processo de teste manualmente, há uma grande chance de erro humano e o processo ficará lento, o que pode afetar o Recovery Time Objective (RTO). Neste blog, veremos como automatizar os testes para atualizar seus bancos de dados PostgreSQL usando o ClusterControl.
Tipo de atualizações de banco de dados
Existem dois tipos de upgrades:Upgrades Secundários e Upgrades Principais.
Atualizações menores
É a atualização mais comum e segura e, na maioria dos casos, é realizada no local. Como nada é 100% seguro, você deve sempre ter backups e nós de espera, então caso algo dê errado com o upgrade, você pode promover um nó de espera na versão anterior, e seus sistemas ainda podem funcionar sem interrupção.
Você pode realizar esse tipo de atualização usando o ClusterControl. Para isso, vá para ClusterControl -> Selecione seu PostgreSQL Cluster -> Gerenciar -> Atualizações.
Em cada nó selecionado, o procedimento de atualização irá:
-
Parar nó
-
Nó de atualização
-
Iniciar nó
O nó mestre em uma topologia PostgreSQL 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, existem diferentes abordagens para fazer atualizações.
Você pode clonar seu cluster de banco de dados atual, atualizá-lo e testar seu aplicativo lá e, quando terminar, se tudo correu bem, você pode recriá-lo para repetir o processo para fazer a atualização real , ou você também pode criar um novo cluster na nova versão, testar seu aplicativo e alternar o tráfego quando estiver pronto, e há mais opções... O uso de Load Balancers é útil aqui para melhorar a alta disponibilidade. 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.
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, escolha um backup e você verá 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 node e desabilite o firewall ou AppArmor/SELinux (dependendo do SO). 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 desligar o banco de dados serviço até o próximo trabalho 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 esse 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 PostgreSQL Cluster -> Backup -> Criar Backup e escolha a opção Backup Agendado. O recurso automático de verificação de backup está disponível apenas para backups agendados.
Na segunda etapa, certifique-se de ter ativado a opção Verify Backup, e preencha as informações solicitadas.
Quando o trabalho for concluído, você poderá ver o ícone de verificação no ClusterControl Seção de backup, a mesma 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.
Criar cluster a partir do backup
Outra maneira de criar um ambiente de teste é criando um novo cluster a partir de um backup de seu cluster primário. Para isso, vá para ClusterControl -> Selecione seu cluster PostgreSQL -> Backup. Lá, escolha o backup a ser restaurado na lista e selecione Restaurar -> Criar cluster do backup.
Esta opção criará um novo cluster PostgreSQL a partir do backup selecionado.
Você precisa adicionar as credenciais do SO e do banco de dados e as informações para implantar o novo aglomerado. Quando esse trabalho for concluído, você verá o novo cluster na interface do usuário do ClusterControl.
Replicação de cluster para cluster
Desde o ClusterControl 1.7.4, existe um recurso chamado Replicação de cluster para cluster. Ele permite que você tenha uma replicação em execução entre dois clusters autônomos.
Criando uma replicação de cluster para cluster
Vá para ClusterControl -> Selecione seu PostgreSQL Cluster -> Cluster Actions -> Create Slave Cluster.
O cluster escravo será criado por streaming de dados do cluster primário atual.
Você deve especificar as credenciais SSH e a porta, um nome para seu cluster escravo, e se você deseja que o ClusterControl instale o software e as configurações correspondentes para você.
Após configurar as informações de acesso SSH, você deve definir a versão do banco de dados, datadir, porta e credenciais de administrador. Como ele usará a replicação de streaming, certifique-se de usar a mesma versão do banco de dados e as credenciais devem ser as mesmas usadas pelo Cluster Primário.
Nesta etapa, você precisa adicionar o servidor ao novo cluster escravo . Para esta tarefa, você pode inserir o endereço IP ou o nome do host do nó do banco de dados.
Você pode monitorar o status do trabalho no monitor de atividades do ClusterControl. Quando a tarefa estiver concluída, você poderá ver o cluster na tela principal do ClusterControl.
Recuperação automática e failover
Com o recurso Autorecovery habilitado, em caso de falha, o ClusterControl irá promover o nó standby mais avançado para primário, além de notificá-lo sobre o problema. Ele também faz failover do restante dos nós em espera para replicar a partir do novo servidor primário.
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 -> Selecione seu PostgreSQL Cluster -> Nodes -> Selecione o Node a ser promovido -> Node Actions -> Promote Slave.
Dessa forma, se algo der errado durante a atualização, você pode 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=9 \
--check-pkg-upgrades \
--log
$ s9s cluster --cluster-id=9 \
--available-upgrades \
--nodes=10.10.10.122 \
--log \
--print-json
$ s9s cluster --cluster-id=9 \
--upgrade-cluster \
--nodes=10.10.10.122 \
--logVerificar backups
$ s9s backup --verify \
--backup-id=2 \
--test-server=10.10.10.124 \
--cluster-id=9 \
--logReplicação de cluster para cluster
$ s9s cluster --create \
--cluster-name=PostgreSQL-c2c \
--cluster-type=postgresql \
--provider-version=13 \
--nodes=10.10.10.125 \
--os-user=root \
--os-key-file=/root/.ssh/id_rsa \
--db-admin=admin \
--db-admin-passwd=********* \
--vendor=postgres \
--remote-cluster-id=9 \
--logPromover Nó Escravo
$ s9s cluster --promote-slave \
--cluster-id=9 \
--nodes='10.10.10.122' \
--logConclusão
As atualizações são tarefas necessárias, mas demoradas, pois você precisa testar seu aplicativo para evitar problemas durante o processo. Implantar um ambiente de teste sempre que você precisar atualizar e mantê-lo atualizado sem qualquer ferramenta de automação pode ser difícil.
O ClusterControl permite que você execute atualizações menores da interface do usuário ou CLI do ClusterControl ou até mesmo implante 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.
