Configurando Slots de Failover no PostgreSQL-17

O PostgreSQL 17 introduz slots de failover que melhoram 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 sem interrupções, mesmo após um failover para um servidor de espera. O uso de slots de failover permite que os slots de replicação lógica sejam sincronizados automaticamente entre os nós primários e de espera, 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 de alta disponibilidade PostgreSQL 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 contínua.

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 Slot: Os servidores de standby não tinham conhecimento dos slots de replicação lógica no primário. Essa falta de sincronização levava a um reset completo dos fluxos de replicação em caso de failover.

**Melhorias no PostgreSQL 16**

**Decodificação Lógica Mínima**

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

• Decodificação Mínima no Standby: Isso permitiu que os servidores de standby decodificassem os logs WAL para se prepararem para a replicação lógica, possibilitando slots pré-carregados para uso em caso de failover.
• Failover Mais Rápido: Ao pré-decodificar as alterações do WAL no standby, foi possível reduzir o atraso de replicação ao promover um standby para primário. No entanto, ainda era necessária alguma configuração manual para garantir um failover suave.

**PostgreSQL 17: O Grande Avanço – Slots de Failover**

• Slots de Failover: A introdução dos slots de failover no PostgreSQL 17 elimina a necessidade de intervenção manual, sincronizando automaticamente os slots de replicação lógica entre os servidores primário e de standby.
• 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 quando o nó primário está ativo.
• Transição sem emendas: Após a falha, o servidor de 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. Em nosso exemplo, usaremos os seguintes nós:

1. NodeA (Servidor Primário)
2. NodeB (Standby Físico)
3. NodeC (Assinante Lógico)

Pré-requisitos

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

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

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

1.1 Inicialize o cluster em NodeA

Depois de 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 de Replicação

O arquivo pg_hba.conf gerencia a autenticação do cliente para o servidor PostgreSQL. Adicione a seguinte entrada em /home/pgedge/nodeA/pg_hba.conf para garantir 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

Então, 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 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

Então, 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), configurando:

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 Ativar a Sincronização do Slot de Failover

Use o cliente psql para fazer login no NodeB:

psql -d postgres -p 5433 

Em seguida, utilize as seguintes instruções para configurar a replicação para o 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 o NodeB:

pg_ctl -D /home/pgedge/nodeB restart 

2.4 Verificar a Sincronização do Slot

Depois, reconecte ao NodeB com o 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 o NodeC

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

mkdir -p /home/pgedge/nodeC

​

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

Em seguida, edite o arquivo /home/pgedge/nodeC/postgresql.conf, configurando 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 no NodeC

Use o seguinte comando para criar uma assinatura no 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 a 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 do NodeA, seguida pela promoção do standby para primário do NodeB:

pg_ctl -D /home/pgedge/nodeA stop

​

pg_ctl -D /home/pgedge/nodeB promote

4.2 Atualizar a Assinatura no NodeC

Após promover o nó B, faça login no Nó C e atualize a conexão para refletir que o Nó B é 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 Nó-B (agora o primário):

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

Verifique a replicação no Nó-C:

SELECT * FROM foo;

Conclusão

O recurso de slot de failover do PostgreSQL 17 permite um failover sem interrupções em ambientes de replicação lógica. Seguindo os passos descritos neste guia, você pode criar um cluster de alta disponibilidade que garante 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.