Por Éverton Trindade e Anderson Alves de Souza

Olá, pessoal!

Hoje daremos continuidade a nossa saga referente a replicação lógica no PostgreSQL. No post anterior referente a esse mesmo assunto, abordamos sobre os possíveis Problemas de Inconsistência e Quebra de Replicação Lógica no PostgreSQL

Para fins de demonstração, nesse post utilizamos a versão 14 do PostgreSQL, um banco de dados denominado “pagila” e duas VMs no Azure baseado na distribuição RedHat, ambos atualizados e com mesmo versionamento de Kernel.

Para facilitar o processo, vamos ignorar a etapa de restore e configuração do banco de dados pagila. Focaremos apenas na configuração da replicação lógica. Na imagem abaixo temos as tabelas do banco a serem replicadas:

Para fins de validação, confirmaremos a existência dos dez primeiros registros da tabela actor:

Para iniciarmos o processo, precisamos estabelecer conexão com o banco pagila no servidor PGSQL-01:

A partir daqui criaremos o publication, o qual denominaremos de pb_replica e servirá como ponte para criarmos um subscription no servidor secundário (réplica). Aqui faremos a replicação de todas as tabelas do banco pagila sem mencionar tabelas ou comandos específicos, embora não recomendemos em ambientes de produção por questões de performance. Isso porque no PostgreSQL você pode definir se a replicação permitirá ou não comandos do tipo INSERT, UPDATE, DELETE etc. Além de especificar quais tabelas serão replicadas.

Abaixo podemos confirmar os dados do publication criado anteriormente no servidor PGSQL-01:

Aqui confirmamos não haver registros na tabela actor no servidor réplica:

Agora estabeleceremos conexão com o banco pagila do servidor PGSQL-03 para então criarmos o subscription que estabelecerá comunicação com o publication.

Para criarmos essa subscription, a qual chamaremos de sb­_replica, faz-se necessário passar cinco parâmetros, são eles:

host – ip do servidor primário
port – porta utilizado pelo PostgreSQL no servidor primário
dbname – nome do banco cujas tabelas serão replicadas
user – usuário utilizado para o processo de replicação
password – senha do usuário configurado no processo de replicação

Abaixo temos os dados de sb_replica após o processo de criação da subscription:

Pelo que percebemos a nossa replicação já está funcionando. Para fins de confirmação, validaremos se existem ou não registros na tabela actor:

E com isso temos a replicação de todas as tabelas do banco pagila no servidor PGSQL-03, conforme processo lógico demonstrado abaixo.

Caso as tabelas permaneçam sem registros, o que podemos fazer é atualizar ou forçar a replicação. Caso o problema persista, faz-se necessário rever as configurações ou parametrizações do processo. Mas isso ficará para um outro momento.

Por hoje era isso pessoal, até o próximo post! 😊