Configurando Slots de Failover no PostgreSQL-17

O PostgreSQL 17 introduz slots de failover que aprimoram as configurações de alta disponibilidade. Um slot de replicação garante que os dados permaneçam confiáveis e consistentes entre os nós durante a replicação, enquanto um slot de failover garante consistência entre os nós, especificamente durante e após um failover.

Os slots de failover são um recurso poderoso que garante que a replicação lógica possa continuar de forma ininterrupta, mesmo após um failover para um servidor de reserva. O uso de slots de failover permite que os slots de replicação lógica sejam automaticamente sincronizados entre os nós primários e de reserva, reduzindo significativamente o tempo de inatividade e a necessidade de intervenção manual durante um failover.

Este guia irá orientá-lo na configuração de um cluster PostgreSQL de alta disponibilidade usando o novo recurso de slots de failover. Ao final, você terá uma configuração de replicação robusta capaz de lidar com um failover de forma fluida.

Por que os Slots de Failover Importam do Ponto de Vista Histórico

Desafios no PostgreSQL 15

• Slots de Replicação Vinculados ao Nó Primário: No PostgreSQL 15, os slots de replicação eram criados apenas no servidor primário. Todos os slots de replicação lógica eram perdidos se o servidor primário falhasse, levando a atrasos significativos na replicação e perda de dados.
• Gerenciamento Manual de Failover: Durante cenários de failover, os administradores recriavam manualmente os slots de replicação no novo servidor primário, o que aumentava a complexidade, introduzia erros e prolongava o tempo de inatividade.
• Sem Sincronização de Slots: Servidores de espera não tinham como saber sobre os slots de replicação lógica no primário. Essa falta de sincronização levou a uma redefinição completa dos fluxos de replicação se um failover ocorresse.

Melhorias no PostgreSQL 16

Decodificação Lógica Mínima

O PostgreSQL 16 introduziu um recurso chamado decodificação lógica mínima em servidores de espera:

• Decodificação Mínima em Espera: Isso permitiu que servidores de espera decodificassem logs WAL para se preparar para replicação lógica, permitindo slots pré-aquecidos para uso caso um failover ocorresse.
• Failover Mais Rápido: Ao pré-decodificar alterações WAL no servidor de espera, foi possível reduzir o atraso de replicação ao promover um servidor de espera para o primário. No entanto, isso ainda exigia alguma configuração manual para garantir um failover suave.

PostgreSQL 17: O Mudador de Jogo – Slots de Failover

• Slots de Failover: A introdução de slots de failover no PostgreSQL 17 elimina a necessidade de intervenção manual ao sincronizar automaticamente os slots de replicação lógica entre os servidores primário e de espera.
• Sincronização Automática: O novo trabalhador de sincronização de slots garante que os slots habilitados para failover (failover = true) estejam sempre sincronizados, mesmo enquanto o nó primário estiver ativo.
• Transição sem emendas: Após a falha, o servidor em espera pode assumir como primário sem perder nenhum slot de replicação, garantindo zero perda de dados e replicação contínua.

Criando um Cluster de Alta Disponibilidade Com Slots de Failover

Esta seção irá guiá-lo na criação de um cluster de alta disponibilidade do PostgreSQL com slots de failover. No nosso exemplo, usaremos os seguintes nós:

1. NóA (Servidor Primário)
2. NóB (Standby Físico)
3. NóC (Assinante Lógico)

Pré-requisitos

Antes de começarmos, certifique-se de que você tenha:

• PostgreSQL 17 instalado em todos os três nós.
• Acesso SSH sem senha entre cada nó.
• Um entendimento básico de PostgreSQL, replicação do PostgreSQL, e arquivos de configuração do PostgreSQL.

Passo 1: Configurando o Nó Primário (NóA)

1.1 Inicialize o cluster em NodeA

Após instalar o PostgreSQL no nó primário, inicialize o cluster; você pode usar os seguintes comandos:

mkdir -p /home/pgedge/nodeA

​

initdb -D /home/pgedge/nodeA --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeA -l /home/pgedge/logs/nodeA.log start 

1.2 Configure a replicação no arquivo postgresql.conf

Após inicializar o cluster, edite o arquivo postgresql.conf, localizado por padrão em /home/pgedge/nodeA/postgresql.conf. Defina os seguintes valores de parâmetros:

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

synchronous_standby_names = '*'

​

synchronized_standby_slots = 'sb1_slot'

​

port = 5432

1.3 Atualize o arquivo pg_hba.conf permitindo o Acesso à Replicação

O arquivo pg_hba.conf gerencia a autenticação do cliente para o servidor PostgreSQL. Adicione a seguinte entrada a /home/pgedge/nodeA/pg_hba.conf para garantir o acesso a um usuário de replicação:

host replication replicator 127.0.0.1/32 md5

Em seguida, recarregue a configuração:

pg_ctl -D /home/pgedge/nodeA reload 

1.4 Crie um Usuário de Replicação

Em seguida, faça login no PostgreSQL e crie o usuário de replicação:

psql -d postgres -p 5432 

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD 'replicator_password';

1.5 Crie uma Tabela e Configure uma Publicação

Em seguida, você precisará criar uma tabela e criar uma publicação associada:

CREATE TABLE foo (c1 INT PRIMARY KEY);

​

GRANT SELECT ON foo TO replicator;

​

CREATE PUBLICATION mypub FOR TABLE foo;

Passo 2: Configurando o Standby Físico (NodeB)

2.1 Inicialize o NodeB

Após instalar o PostgreSQL, inicialize o NodeB:

mkdir -p /home/pgedge/nodeB 

​

initdb -D /home/pgedge/nodeB --no-locale -E UTF8 

​

pg_ctl -D /home/pgedge/nodeB -l /home/pgedge/logs/nodeB.log start

2.1 Crie um Backup Base

Em seguida, use pg_basebackup para fazer um backup do cluster:

mkdir -p /home/pgedge/nodeB 

​

pg_basebackup -D /home/pgedge/nodeB -R -X stream -P -h localhost -p 5432 -U replicator

2.2 Configure o postgresql.conf no Node-B

Modifique o arquivo postgresql.conf (localizado em /home/pgedge/nodeB/postgresql.conf), definindo:

port = 5433

​

primary_conninfo = 'host=localhost port=5432 user=replicator password=replicator_password dbname=postgres application_name=sb1_slot'

​

primary_slot_name = 'sb1_slot'

​

hot_standby_feedback = on

​

sync_replication_slots = on

2.3 Habilitar a Sincronização do Slot de Failover

Use o cliente psql para fazer login em NodeB:

psql -d postgres -p 5433 

Em seguida, utilize as seguintes instruções para configurar a replicação para NodeB:

ALTER SYSTEM SET sync_replication_slots = on;

​

ALTER SYSTEM SET hot_standby_feedback = on;

​

ALTER SYSTEM SET synchronized_standby_slots = 'sb1_slot';

Saia do cliente psql e reinicie NodeB:

pg_ctl -D /home/pgedge/nodeB restart 

2.4 Verificar a Sincronização do Slot

Depois, reconecte-se a NodeB com psql e verifique se os slots estão sincronizados:

SELECT slot_name, failover, synced FROM pg_replication_slots;

Passo 3: Configurando o Assinante Lógico (NodeC)

3.1 Inicialize o cluster e configure NodeC

Após instalar o PostgreSQL, inicialize o cluster; você pode usar os seguintes comandos:

mkdir -p /home/pgedge/nodeC

​

initdb -D /home/pgedge/nodeC --no-locale -E UTF8

Em seguida, edite o arquivo /home/pgedge/nodeC/postgresql.conf, definindo os seguintes valores de parâmetros:

wal_level = logical

​

max_replication_slots = 10

​

max_wal_senders = 10

​

sync_replication_slots = on

​

port = 5444

​

After editing the configuration file, start NodeC:

​

pg_ctl -D /home/pgedge/nodeC -l /home/pgedge/logs/nodeC.log start

3.2 Criar uma Assinatura em NodeC

Use o seguinte comando para criar uma assinatura em NodeC:

CREATE SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5432 user=replicator password=replicator_password' PUBLICATION mypub WITH (failover = true);

Passo 4: Simulando o Failover e Garantindo Continuidade

Você pode usar os seguintes comandos para simular um failover e confirmar que a replicação continua e a integridade dos dados é preservada.

4.1 Simulando um Failover

Use os seguintes comandos para simular uma falha de NodeA, seguida pela promoção de standby para primário de NodeB:

pg_ctl -D /home/pgedge/nodeA stop

​

pg_ctl -D /home/pgedge/nodeB promote

4.2 Atualizar a Assinatura em NodeC

Após promover o nodeB, faça login no NodeC e atualize a conexão para refletir que o NodeB é agora o nó primário:

ALTER SUBSCRIPTION foosub DISABLE;

​

ALTER SUBSCRIPTION foosub CONNECTION 'dbname=postgres host=localhost port=5433 user=replicator password=replicator_password';

​

ALTER SUBSCRIPTION foosub ENABLE;

4.3 Verificar Continuidade dos Dados

Para testar a replicação, use psql para fazer login no Node-B (agora o primário):

INSERT INTO foo VALUES (3), (4);

Verifique a replicação no Node-C:

SELECT * FROM foo;

Conclusão

O recurso de slot de failover do PostgreSQL 17 permite um failover contínuo em ambientes de replicação lógica. Seguindo os passos descritos neste guia, você pode criar um cluster de alta disponibilidade que garante um fluxo de dados ininterrupto, mesmo durante uma falha do servidor primário.

Ao otimizar as configurações e aproveitar as novas capacidades do PostgreSQL 17, você pode criar uma infraestrutura de banco de dados resiliente e eficiente para suas aplicações críticas.