Olá pessoal!

Hoje falaremos um pouco sobre possíveis problemas que podem levar à inconsistência e quebra da replicação lógica no PostgreSQL. Assim como no SQL Server, nesse tipo de replicação o servidor primário é denominado publication e o servidor secundário como subscription.

Ao contrário da replicação física, nesse modelo é possível gravar ou alterar dados no servidor de réplica fazendo uso de instruções do tipo DML e DDL. Isso quer dizer que comandos como INSERT, UPDATE, DELETE ou ALTER podem ser executados no lado subscriber sem problema algum.

Mas no que isso pode implicar?
Para fins de demonstração, nesse post utilizamos duas VMs baseado na distribuição RedHat, ambos com tabela de mesmo nome.

Compartilharemos a seguir alguns exemplos:

Primeira situação: inserção de dado(s) no subscriber

Os dados podem ser inseridos numa tabela qualquer no servidor slave sem problema algum, desde que não seja inserido um registro idêntico no servidor primário (master). Considere o exemplo abaixo:

Primeiro inserimos um registro na tabela denominada cdb no subscriber:

INSERT INTO cdb VALUES (100, 1024, ‘teste’);

Mas ao inserir o mesmo registro no publisher nos deparamos com o seguinte erro:

Com isto a replicação será interrompida e os segmentos de WAL se acumularão, podendo parar até mesmo o serviço do postgres no servidor principal caso haja falha no processo de monitoramento.

Segunda situação: atualização de registro(s) no subscriber

A instrução UPDATE pode ser executado na réplica desde que tal privilégio seja concedido ao(s) usuário(s). Nesse caso a replicação não será interrompida, mas teremos inconsistência nos dados entre os dois servidores, pois o publisher não sabe qual registro foi alterado no subscriber.

Primeiro inserimos um novo registro no master:

INSERT INTO cdb VALUES (300, 500, ‘update’);

A replicação é instantânea, então atualizaremos esse mesmo registro no subscriber:

Atualizaremos o registro de ID 300 no Publisher:

Com isso percebemos que houve uma sobrescrita no mesmo registro no subscriber, onde o campo value de valor 1700 foi substituído pelo valor 9730:

Terceira situação: remoção de registro(s)

Esse tipo de atividade ocasiona parada no processo de replicação também, isso porque o publisher não encontrará o mesmo registro no subscriber ao tentar replicar qualquer tipo de alteração na respectiva linha da tabela.

Em resumo, percebemos que o problema consiste no fato de que, como a replicação lógica é unidirecional, então quaisquer alterações no subscriber não será replicado para o publisher. De tal modo que pode implicar na inconsistência dos dados ou até mesmo na quebra desse tipo de replicação.

Mas como configurar a replicação ou até mesmo sincronizar novamente as tabelas ou o banco de dados após interrupção do processo sem a necessidade de refazer a replicação?
Isso já é um outro assunto e ficará para um próximo post.

Até mais! 😊