Até a versão 8.4 o PostgreSQL conta com a replicação conhecida como warm standby. Esta replicação é baseada em arquivos e não cria um canal de comunicação entre os servidores master e slave. Neste tipo de replicação, o servidor master envia segmentos de logs para o servidor slave com os seguintes critérios:

• ocorrência de checkpoint de acordo com o intervalo de tempo definido no parâmetro checkpoint_timeout;
• preenchimento de certa quantidade de segmentos de logs de 16 MB, definida no parâmetro checkpoint_segments;
• ocorrência de cópia de segmentos de logs de acordo com intervalo de tempo definido no parâmetro archive_timeout.

A ferramenta do contrib do PostgreSQL, pg_standby, inicia um processo no servidor slave que aguarda por segmentos de logs enviados de tempos em tempos pelo servidor master e aplica-os no servidor de contingência. Porém, o servidor de contingência permanece iniciado exclusivamente para o processo pg_standby, ou seja, em modo de recuperação.

Replicação Warm Standby

Portanto, tem-se nesta solução de alta disponibilidade um intervalo razoável de atualização do servidor slave, além do mesmo não permitir acesso para consultas.
A partir da versão 9.0, a opção da criação de um canal de comunicação (stream) entre os servidores foi implementada, tornando a replicação mais eficiente. Esta nova funcionalidade é chamada de streaming replication.

A streaming replication permite que um servidor slave permaneça em comunicação constante como servidor master, facilitando o recebimento de segmentos de logs. Isto é possível devido aos processos Walreceiver e Walsender, iniciados nos servidores slave e master respectivamente. Esses processos utilizam um canal de comunicação criado via TCP/IP. A criação desse canal inicia-se quando o Walreceiver envia uma requisição de conexão ao servidor master, se a conexão for estabelecida, o processo Walsender é criado. A partir de então o Walsender envia ao Walreceiver as alterações efetivadas no servidor master a serem aplicadas no servidor slave.

Diferente da replicação warm standby, a streaming replication envia somente as alterações, sem considerar critérios de rotação de segmentos de logs definidos no servidor master.

Assim como na warm standby, a streaming replication também é uma replicação assíncrona, por isso ainda há um pequeno atraso entre submeter uma transação no servidor master e essas mudanças se tornarem visíveis no servidor slave. O atraso, no entanto, é muito menor se comparado com o envio de logs baseado em arquivo.

Replicação Streaming Replication/Hot Standby

Um indicador importante da eficiência da streaming replication é a quantidade de registros do WAL gerados no servidor master, mas ainda não aplicado no servidor slave. Pode-se calcular esse atraso, comparando a localização atual do WAL no servidor master com a localização do WAL recebido pelo servidor slave. Essas informações podem ser recuperadas usando as funções pg_current_xlog_location no servidor master e pg_last_xlog_receive_location no servidor slave. A ultima localização do WAL recebida pelo servidor slave também é exibida no status do processo Walreceiver.

Além desta nova característica, o sistema de replicação nativo do PostgreSQL, conta com uma nova funcionalidade, na qual as bases replicadas permanecem em modo read-only, onde são possíveis somente comandos de leitura (hot standby).

O termo hot standby se refere à capacidade do servidor slave mover operações de recuperação para operações normais, ou seja, possibilitar a execução de consultas ao mesmo tempo em que as alterações efetivadas no servidor master estejam sendo replicadas. Isto é útil tanto para fins de replicação quanto para restaurar um backup para um estado desejado com grande precisão (PITR).

A replicação streaming replication/hot standby garante a segurança sem afetar significativamente a performance do servidor de produção. A replicação do servidor master para vários slaves possibilita a definição de estratégias de alta disponibilidade, sem a necessidade de ferramentas de terceiros.

Portanto o PostgreSQL 9.0, realça ainda mais o objetivo da comunidade de software livre em desenvolver um SGBD cada vez mais avançado e robusto. Visando assim, atender as necessidades de ambientes corporativos que exigem segurança, performance e alta disponibilidade dos dados.

Este tipo de replicação já faz parte do conteúdo do curso de Alta Disponibilidade promovido pela Dextra Sistemas. Esta e outras estratégias de replicação praticadas no treinamento, fornecem ao aluno o conhecimento necessário para definir estratégias de alta disponibilidade voltadas a diversos ambientes.