O PostgreSQL é um S.G.B.D. que permite diferentes modelos de replicação de dados.

A replicação via Log Shipping, por exemplo, esteve presente no PostgreSQL desde a versão 8. Já a replicação via streaming e a replicação lógica nativa desde as versões 9 e 10, respectivamente. Estas duas últimas sendo marcos importantes na evolução do PostgreSQL.

Vamos entender um pouco melhor sobre cada um desses tipos de replicação.

Replicação Física

A replicação física copia blocos de dados, byte por byte. Dessa forma, a réplica torna-se uma imagem do cluster primário.

Podemos configurar este tipo de replicação de duas formas.

Log Shipping

Neste modelo, o servidor primário gera arquivos de WAL (Write-Ahead Log – o log de transações do PostgreSQL) de 16 MB. Em seguida, o servidor de réplica busca estes arquivos e os replica. Vale ressaltar que, além disso, esses arquivos são arquivados e ficam disponíveis para replicação somente após atingirem esses 16 MB. Por isso, esse comportamento pode gerar pequenos atrasos na replicação.

Streaming

No modelo de replicação via streaming, o WAL do servidor primário replica as transações para o secundário, byte por byte, pela conexão de rede, tornando a replicação praticamente em tempo real.

Na replicação de dados via streaming, deve-se escolher se a replicação será em modo assíncrono ou síncrono:

Assíncrono:

Por padrão a replicação acontece no modo assíncrono. Deste modo, assim que os dados são escritos no primário, o cliente recebe o retorno da execução.

Síncrono:

Já no modo síncrono, o cliente receberá o retorno somente após o servidor secundário concluir a replicação dos dados. Dessa forma, este modelo garante zero perda de dados, mas, em contrapartida, adiciona latência a cada transação.

É importante destacar que esta replicação copia todo o cluster. Portanto, não podemos excluir objetos específicos desse processo.

Replicação Lógica

A replicação lógica, diferentemente da física, não copia os blocos binários. Ao invés disso, ela trabalha com o WAL, rastreando e reaplicando os comandos das transações.

O modelo utilizado é o de Publisher e Subscriber. Aqui, o Publisher é a origem dos dados. A partir de sua configuração, um processo captura no WAL as alterações realizadas nos objetos selecionados para replicação e espera pela solicitação do Subscriber. O Subscriber, por sua vez, é o destino dos dados. Ele se conecta à origem, busca e aplica as alterações no destino.

Neste tipo de replicação, podemos selecionar tabelas e, até mesmo, definir quais colunas e linhas serão replicadas.

Qual é o melhor tipo de replicação para o meu cenário?

Como a replicação lógica permite uma replicação mais granular, ela se mostra mais interessante em situações em que queremos consultar sempre tabelas específicas a partir de um servidor secundário, preservando a utilização de recursos em um servidor de escrita, por exemplo. Vale ressaltar que, como a replicação acontece transação por transação, um alto número de alterações nas tabelas replicadas impactará o tempo de replicação dessas informações.

A replicação física, por replicar inteiramente o cluster, é interessante para alta disponibilidade, disaster recovery e, até mesmo, para uma réplica de leitura. Além disso, é importante considerar que, neste tipo de replicação, precisamos disponibilizar no servidor de réplica a mesma infraestrutura do servidor primário.

Por fim, espero que este post tenha sido esclarecedor e possa ajudá-lo em uma possível decisão.

Até a próxima!

Por Jonas Natario