Alta disponibilidade do PostgreSQL com SafeKit: Instale o módulo postgresql.safe para failover

Guia de instalação rápida de alta disponibilidade para PostgreSQL

Este guia explica como configurar um cluster de espelhos para PostgreSQL utilizando SafeKit, garantindo failover automático e replicação síncrona sem necessidade de armazenamento partilhado.

Para obter ajuda, pode utilizar SafeKit AI 🤖.

1. Visão geral

• Arquitetura: Utiliza um sistema de dois nós (Primário/Secundário).
• Proteção de dados: Implementa a replicação síncrona em tempo real para zero perda de dados (RPO=0).

2. Instalação

• Programas: Instale o motor SafeKit em ambos os servidores.
• Módulo: Descarregue o pré-configurado postgresql.safe.safe módulo de aplicação.

3. Configuração

• Consola Web: Configure as pastas específicas que contêm os ficheiros PostgreSQL.
• Monitorização: Comece a monitorizar e a proteger a aplicação PostgreSQL.

Limitações de Alta Disponibilidade do SafeKit

Visão geral da solução SafeKit/PostgreSQL

A solução é descrita aqui: 💡A alta disponibilidade mais simples do PostgreSQL: replicação síncrona e failover de 2 nós.

Instalação da solução SafeKit/PostgreSQL em Windows e Linux (postgresql.safe)

Pré-requisitos

• Necessita do PostgreSQL instalado em 2 nós (máquinas virtuais ou servidores físicos).

Instalação do pacote em Windows

• Descarregue e instale a versão gratuita do SafeKit em 2 nós Windows.
  Nota: a versão gratuita inclui todas as funcionalidades do SafeKit. No final da avaliação, poderá ativar as chaves de licença permanentes sem desinstalar o pacote.
• Ao concluir a instalação do pacote, selecione Set console credentials and firewall rules now e configure uma palavra-passe para o admin utilizador da consola SafeKit.
  Defina a mesma palavra-passe em todos os nós.
• Apagar das verificações antivírus C:/safekit/ (o diretório de instalação padrão) e todas as pastas replicadas que vai definir.
  Os antivírus podem enfrentar desafios de deteção com o SafeKit devido à sua estreita integração com o sistema operativo, mecanismos de IP virtual, replicação em tempo real e reinicialização de serviços críticos.

Descarregue SafeKit (Windows) >

Instalação do módulo em Windows

• Descarregue o módulo postgresql.safe. O módulo é gratuito. Contém os ficheiros userconfig.xml e os scripts de reinicialização.
• Colocar postgresql.safe sob C:/safekit/Application_Modules/generic.

Download postgresql.safe (Windows) >

Instalação do pacote em Linux

• Instale a versão gratuita do SafeKit em 2 nós Linux. Nota: a avaliação gratuita inclui todas as características do SafeKit. No final da avaliação, poderá ativar as chaves de licença permanentes sem desinstalar o pacote.
• Após o download do pacote safekit_xx.bin, execute-o para extrair o script rpm e safekitinstall e, em seguida, execute o safekitinstall roteiro
• Resposta sim para configuração automática da firewall
• Defina a palavra-passe da consola web e o utilizador padrão admin. Defina a mesma palavra-passe em todos os nós.

Descarregue SafeKit (Linux) >

Instalação do módulo em Linux

• Descarregue o módulo postgresql.safe.
  O módulo é gratuito. Contém os ficheiros userconfig.xml e os scripts de reinicialização.
• Colocar postgresql.safe sob /opt/safekit/Application_Modules/generic/.

Transferir postgresql.safe (Linux) >

Configuração passo a passo da solução SafeKit/PostgreSQL

Pré-requisitos

• Aplicação PostgreSQL instalada em 2 nós.
• Total de dados replicados limitado a alguns terabytes — além disso, o tempo de ressincronização torna-se significativo.
• Interligação mínima de 1 Gb/s entre nós (recomenda-se 10 Gb/s para uma ressincronização mais rápida).
• O failover IP requer ambos os nós no mesmo LAN ou LAN estendido (L2) — redes L3 não suportadas com encaminhamento (exceto com 🛠️ balanceadores de carga na nuvem).

1. Inicie a consola SafeKit

• Inicie a consola web num navegador num nó do cluster, conectando-se ao http://localhost:9010.
• Introduza admin como nome de utilizador e palavra-passe definidos durante a instalação.

Também é possível executar a consola num browser numa estação de trabalho externa ao cluster.

⚠️ A configuração do SafeKit é feita em ambos os nós a partir de um único browser.

ℹ️ Para proteger a consola web, consulte 🛠️ 11. Proteger o serviço web SafeKit no Manual do utilizador.

2.º Configure endereços de nós

• Introduza os endereços dos nós IP, prima Tab key para verificar a conectividade e preencher os nomes dos nós. Se node1 ou node2 tiver uma cor vermelha, verifique a conectividade do browser com ambos os nós e verifique a firewall em ambos os nós para 🛠️ resolução de problemas.
• Em seguida, clique em Save and apply para guardar a configuração.
• Verifique a mensagem Success ✅ em ambos os nós.
• Se a configuração Failure ❌ ocorrer num nó, abra o acordeão ▼ desse nó e reveja as mensagens. Note que pode utilizar SafeKit AI 🤖 para obter assistência.

ℹ️ Se desejar, pode adicionar um novo LAN and nodes (primeiro ➕) para criar uma segunda pulsação e uma rede de replicação dedicada.

ℹ️ Se clicar em Advanced configuration, é apresentado o ficheiro cluster.xml. Este ficheiro é preenchido automaticamente pela consola e implementado nos nós.

3.º Selecione um módulo

• Em New module, clique no módulo postgresql.safe.

ℹ️ No banner azul na parte superior, 🛜 node1 representa o nó de ligação da consola. Este nó retransmite pedidos para node2 quando necessário.

ℹ️ A consola procura xxx.safe no diretório Application_Modules/generic/ no nó de ligação (node1) se tiver colocado lá um módulo durante a instalação.

4.º Configure o módulo

• Em Module startup at boot, escolha um arranque automático do módulo no arranque sem demora.
• Em Macros/SERVICES, introduza os nomes dos serviços da sua aplicação, pela ordem de arranque, separados por vírgulas. Veja esta captura de ecrã para um exemplo visual dos serviços Milestone XProtect 🖼️.
• Em Heartbeat networks, deve ter uma rede de pulsação única na qual a replicação é feita. Se tiver adicionado um LAN privado no passo 2, pode configurar duas pulsações com o fluxo de replicação no LAN privado.
• Em Virtual IP addresses, introduza um endereço IP virtual. Um endereço IP virtual é um endereço IP padrão na mesma rede IP (mesma sub-rede) que os endereços IP de ambos os nós.
  Os clientes aplicações devem ser configurados com o endereço IP virtual (ou o nome DNS associado ao endereço IP virtual).
  O endereço virtual IP é alternado automaticamente em caso de falha.
• Em Replicated directories, defina os caminhos dos diretórios a replicar. Verifique se existem em ambos os nós e se contêm os dados da aplicação.
  A replicação de dados e de logs é essencial para uma base de dados.
  Pode criar diretórios replicados adicionais conforme necessário.
  Veja esta captura de ecrã para um exemplo visual da replicação Milestone XProtect SQL 🖼️.
• No Checkers, poderá configurar verificadores, se necessário, como monitorização de processos, verificadores personalizados, TCP, ping ou verificadores de cérebro dividido.
  Por exemplo, se um nome de processo for apresentado em Monitored processes/services, será monitorizado com uma ação de reinicialização em caso de falha. A configuração de um nome de processo incorreto fará com que o módulo pare logo após o seu início.

ℹ️ Se clicar em Advanced configuration, é apresentado o ficheiro userconfig.xml. Este ficheiro é preenchido automaticamente pela consola e implementado nos nós com os scripts de reinicialização.

ℹ️ Numa implementação na nuvem, não precisa de configurar um endereço IP virtual em SafeKit. O IP virtual é gerido ao nível do balanceador de carga de cloud 🛠️ .

ℹ️ Quando aplica a configuração SafeKit, o startup type dos serviços é automaticamente definido como Manual nos serviços Windows. Isto garante que os serviços não são iniciados automaticamente quando o sistema é inicializado, mas, em vez disso, são iniciados apenas quando o próprio módulo é iniciado (o mesmo se aplica ao Linux).

5.º Edite scripts (opcional)

• Este passo é opcional e pode ser ignorado na maioria dos casos, uma vez que os scripts de reinicialização já estão pré-configurados para reiniciar os serviços definidos no passo anterior.
• Assim, clique diretamente em Next step.
• start_prim.ps1 inicia todos os serviços pela ordem especificada na lista SERVICES, enquanto stop_prim.ps1 interrompe todos os serviços pela ordem inversa.
• Além disso, o start_prim.ps1 verifica a inicialização de cada serviço e pára o módulo se algum serviço não iniciar corretamente.

6.º Encriptação de comunicação (opcional)

• Mantenha a encriptação da comunicação entre os nós.

7.º Guarde e aplique

• Save and apply a configuração e os scripts em ambos os nós.

8. Verifique a configuração bem-sucedida

• Verifique a mensagem Success ✅ em ambos os nós e clique em Monitor modules.
• Se a configuração Failure ❌ ocorrer num nó, abra o acordeão ▼ desse nó e reveja as mensagens. Note que pode utilizar SafeKit AI 🤖 para obter assistência.

⚠️ Em Linux, poderá receber um erro neste passo se os diretórios replicados forem pontos de montagem.🛠️ Consulte SK-0030 para resolver o problema.

9. Inicie o nó com os dados atualizados

• Se o nó 1 tiver diretórios replicados atualizados, selecione-o e ⋯ Force start ▶ As primary.

Quando o nó 2 for iniciado, todos os dados serão copiados do nó 1 para o nó 2.

⚠️ Se fizer a escolha errada, corre o risco de sincronizar dados desatualizados em ambos os nós.

⚠️ Supõe-se também que a aplicação PostgreSQL é parada no nó 1 para que SafeKit instale os mecanismos de replicação e depois inicie a aplicação no script start_prim.

⚠️ Utilize Start para arranques subsequentes: SafeKit mantém o servidor mais atualizado. A inicialização do As primary é uma inicialização especial à primeira ou durante operações excecionais.

10. Aguarde a transição para ALONE (verde)

• O nó 1 deve atingir o estado ALONE (verde), o que significa que o IP virtual está configurado e que o script start_prim foi executado no nó 1.

⚠️ Se ALONE (verde) não for atingido ou se a aplicação não for iniciada, analise o porquê com o registo do módulo 🖼️ do nó 1.

• Clique no ícone 🔍 log de node1 para abrir o registo do módulo e procurar mensagens de erro, como um verificador que deteta um erro e interrompe o módulo.
• Clique em start_prim no registo: as mensagens de saída do script são apresentadas à direita e podem ser detetados erros, como um serviço iniciado incorretamente.
• Utilize SafeKit AI 🤖 para obter assistência com mensagens de registo.

⚠️ Se o cluster estiver no estado WAIT (red) not uptodate, STOP (red) not uptodate, pare o nó WAIT e force o seu arranque como primário 🖼️.

11.º Iniciar nó 2

• ⋯ Nó Start 2 com o seu menu contextual.
• Aguarde o estado SECOND (verde).

ℹ️ O nó 2 permanece no estado SECOND (laranja) enquanto ressincroniza os diretórios replicados (copia do nó 1 para o nó 2).

• Isto pode demorar um pouco, dependendo do tamanho dos ficheiros a ressincronizar nos diretórios replicados e da largura de banda da rede.
• Para ver o progresso da cópia, consulte o registo do módulo 🖼️ e as características de replicação 🖼️ do nó 2. Utilize o SafeKit AI 🤖 para obter assistência com as mensagens de registo.

12.º Verifique se o cluster está operacional

• Verifique se o cluster está verde/verde com os serviços PostgreSQL em execução no nó PRIM e não em execução no nó SECOND.

Apenas as alterações dentro dos ficheiros são replicadas em tempo real neste estado.

⚠️ Os componentes clientes dos serviços PostgreSQL devem ser configurados com o endereço virtual IP. A configuração pode ser feita com um nome DNS (caso tenha sido criado um nome DNS e associado ao endereço virtual IP).

13.º Teste

• Pare o nó PRIM fazendo scroll para baixo no seu menu contextual e clicando em Stop.
• Verifique se existe um failover no nó SECOND que se deve tornar ALONE (verde).
• E com o Microsoft Management Console (MMC) em Windows ou com linhas de comando em Linux, verifique o failover dos serviços PostgreSQL (interrompido no nó 1 no script stop_prim e iniciado no nó 2 no script start_prim).

⚠️ Se ALONE (verde) não for atingido em node2 ou se a aplicação não for iniciada, analise o porquê com o registo do módulo 🖼️ do nó 2.

• Clique no ícone 🔍 log de node2 para abrir o registo do módulo e procurar mensagens de erro, como um verificador que deteta um erro e interrompe o módulo.
• Clique em start_prim no registo: as mensagens de saída do script são apresentadas à direita e podem ser detetados erros, como um serviço iniciado incorretamente.
• Utilize SafeKit AI 🤖 para obter assistência com mensagens de registo.

⚠️

• Se tudo estiver bem, inicie o node1, que irá voltar a sincronizar os diretórios replicados do node2.
• Se algo correr mal, pare node2 e force o arranque como 🖼️ primário de node1, que será reiniciado com os seus dados localmente íntegros no momento da paragem.

ℹ️ Encontre mais detalhes, juntamente com vídeos, na Formação Online SafeKit.

14. Suporte

• Para obter suporte, leve 2 SafeKit Snapshots (2 ficheiros . zip), um para cada nó.

ℹ️ Mais informações sobre o suporte aqui.

Demonstração da solução de espelho SafeKit

Vídeo SafeKit: Clustering ao nível da aplicação (8:47)

Neste vídeo, descubra como o SafeKit implementa um cluster de alta disponibilidade espelhado sem a complexidade de uma SAN. Embora esta demonstração utilize o Microsoft SQL Server, a solução funciona de forma idêntica para outras bases de dados e aplicações.

Capítulos

1. 🎬 2 nós com SQL Server (0:32)
2. 🎬 Configure o cluster e o módulo mirror.safe (3:58)
3. 🎬 Iniciar e testar a replicação SQL, migração e failover em caso de falha (4:17)

Implementação passo a passo

• 🛠️ Leia o guia sobre como configurar um cluster espelhado no Windows
• 🛠️ Leia o guia sobre como configurar um cluster espelhado no Linux

🔍 Hub de Navegação de Alta Disponibilidade SafeKit

Explore o SafeKit: Funcionalidades, vídeos técnicos, documentação e teste gratuito