Geralmente, é aconselhável criar os servidores primário e secundário para serem o mais semelhantes possível, pelo menos da perspectiva do servidor de banco de dados. Em particular, os nomes de caminho associados aos espaços de tabelas serão passados sem modificação, portanto os servidores primário e secundário devem ter os mesmos caminhos de montagem para espaços de tabelas, se este recurso for usado. Deve-se ter em mente que, se for ser executado CREATE TABLESPACE no servidor primário, qualquer novo ponto de montagem necessário para o espaço de tabelas deverá ser criado no servidor primário e em todos os servidores em-espera, antes do comando ser executado. O hardware não precisa ser exatamente o mesmo, mas a experiência mostra que manter dois sistemas idênticos é mais fácil do que manter dois sistemas diferentes ao longo da vida útil da aplicação e do sistema. Em qualquer caso, a arquitetura de hardware deve ser a mesma — o envio de, digamos, um sistema de 32 bits para um sistema de 64 bits não funcionará.

De modo geral, não é possível usar log shipping entre servidores com versão principal do PostgreSQL diferentes. É uma política do PostgreSQL Global Development Group não fazer alterações nos formatos de disco durante atualização de versão secundária, portanto é provável que a execução de diferentes níveis de versão secundária entre servidor primário e servidores secundários funcione com êxito. Entretanto, não é oferecido nenhum suporte formal para isto, então se aconselha manter os servidores primário e secundários no mesmo nível de versão, tanto quanto possível. Ao atualizar para uma nova versão secundária, a política mais segura é atualizar primeiro os servidores secundários — é mais provável que uma nova versão secundária seja capaz de ler arquivos de WAL de uma versão secundária anterior, do que o contrário.

O servidor irá entrar no modo em-espera se existir o arquivo standby.signal no diretório de dados quando o servidor for iniciado.

No modo em-espera, o servidor aplica continuamente o WAL recebido do servidor primário. O servidor em-espera pode ler o WAL de um arquivamento de WAL (veja restore_command), ou diretamente do servidor primário em uma conexão TCP (replicação por fluxo). O servidor em-espera também tentará restaurar qualquer WAL localizado no diretório pg_wal da instância em-espera. Isto normalmente acontece após o reinício do servidor, quando o servidor em-espera reproduz novamente o WAL que foi transmitido do servidor primário antes do reinício, mas também é possível copiar manualmente os arquivos para o diretório pg_wal a qualquer momento para reproduzi-los.

Na ativação, o servidor em-espera começa restaurando todos os arquivos de WAL disponíveis no local de arquivamento, chamando o restore_command. Uma vez que chega ao fim dos arquivos de WAL disponível no local de arquivamento, e o restore_command falha, o servidor em-espera tenta restaurar qualquer arquivo de WAL disponível no diretório pg_wal. Se isto falhar, e tiver sido configurada a replicação por fluxo, o servidor em-espera tentará se conectar ao servidor primário e iniciar o fluxo do WAL a partir do último registro válido encontrado no arquivamento ou em pg_wal. Se isto falhar, ou a replicação por fluxo não estiver configurada, ou se a conexão for desconectada posteriormente, o servidor em-espera voltará para a etapa 1, e tentará restaurar o arquivo a partir do arquivamento novamente. Este ciclo de novas tentativas via arquivamento, pg_wal, e replicação por fluxo, continua até que o servidor seja parado ou promovido

O modo em-espera é encerrado e o servidor passa para a operação normal quando é executado o comando pg_ctl promote, ou é chamada a função pg_promote(). Antes da comutação (failover), qualquer WAL imediatamente disponível no arquivamento ou em pg_wal será restaurado, mas não será feita nenhuma tentativa de conexão com o servidor primário.

Configurar o arquivamento contínuo no servidor primário para haver um diretório de arquivamento acessível a partir do servidor em-espera, conforme descrito em Arquivamento contínuo e restauração para um ponto-no-tempo (PITR). O local do arquivamento deverá estar acessível a partir do servidor em-espera, mesmo quando o servidor primário estiver inativo, ou seja, deverá residir no próprio servidor em-espera, ou em outro servidor confiável, e não no servidor primário.

Se for desejado usar a replicação por fluxo, deverá ser configurada a autenticação no servidor primário permitindo conexões de replicação do(s) servidor(es) em-espera; ou seja, criada uma função de banco de dados (role), e fornecida uma entrada ou entradas adequadas no arquivo pg_hba.conf, com o campo do banco de dados definido como replication. Também deve-se garantir que max_wal_senders esteja definido com um valor suficientemente alto no arquivo de configuração do servidor primário. Se forem usados encaixes (slots) de replicação, deve-se assegurar que max_replication_slots esteja configurado suficientemente alto também.

Fazer uma cópia de segurança base conforme descrito em Criação de cópia de segurança base para inicializar o servidor em-espera.

Para configurar o servidor em espera, deve ser restaurada a cópia de segurança base obtida do servidor primário (veja Restauração usando uma cópia de segurança de arquivamento contínuo). Criado o arquivo standby.signal no diretório de dados da instância em-espera. Configurado restore_command como um comando simples para copiar arquivos do arquivamento de WAL. Se for planejado ter vários servidores em-espera para fins de alta disponibilidade, deve-se certificar de que recovery_target_timeline esteja definido como latest (o padrão), para indicar que o servidor em-espera deve levar em conta a linha do tempo definida ao comutar (failover) para outro servidor em-espera.

Se for desejado usar a replicação por fluxo, então primary_conninfo deverá ser preenchida com uma cadeia de caracteres de conexão libpq, incluindo o nome do hospedeiro (ou endereço IP), e quaisquer detalhes adicionais necessários para se conectar ao servidor primário. Se o servidor primário precisar de senha para autenticação, a senha também precisará ser especificada em primary_conninfo.

Se estiver sendo configurado o servidor em-espera para fins de alta disponibilidade, deve ser configurado o arquivamento de WAL, as conexões, e a autenticação, como as do servidor primário, porque o servidor em-espera funcionará como servidor primário após a comutação (failover).

Se estiver sendo usado o arquivamento de WAL, seu tamanho poderá ser minimizado usando o parâmetro archive_cleanup_command para remover arquivos que não são mais necessários para o servidor em-espera. O utilitário pg_archivecleanup é projetado especificamente para ser usado com archive_cleanup_command em configurações típicas de um único servidor em-espera, veja pg_archivecleanup. Note, no entanto, que se o arquivamento estiver sendo usado para fins de cópia de segurança, precisarão ser retidos os arquivos necessários para restaurar pelo menos a partir da cópia de segurança base mais recente, mesmo que não sejam mais necessários para o servidor em-espera.

Um exemplo simples de configuração é:

primary_conninfo = 'host=192.168.1.50 port=5432 user=foo ↵
                    password=foopass ↵
                    options=''-c wal_sender_timeout=5000'''
restore_command = 'cp /path/to/archive/%f %p'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'

Pode-se ter qualquer número de servidores em-espera, mas se for usada replicação por fluxo, deve-se certificar que max_wal_senders esteja definido alto o suficiente no servidor primário para permitir que todos os servidores em-espera possam se conectar simultaneamente.

A replicação por fluxo (streaming) permite que o servidor em-espera fique mais atualizado do que seria possível com o log shipping baseado em arquivo. O servidor em-espera se conecta ao servidor primário, que transmite os registros de WAL para o servidor em-espera conforme são gerados, sem esperar que o arquivo de WAL fique completo.

A replicação por fluxo é assíncrona por padrão (veja Replicação síncrona), caso em que há um pequeno atraso entre a efetivação da transação no servidor primário e as alterações se tornarem visíveis no servidor em-espera. Entretanto, este atraso é muito menor do que acontece com o log shipping baseado em arquivo, sendo geralmente menos de um segundo, supondo-se que o servidor em-espera seja poderoso o suficiente para acompanhar a carga. Com a replicação por fluxo, não é necessário configurar archive_timeout para reduzir a janela de perda de dados.

Se estiver sendo usada a replicação por fluxo sem arquivamento contínuo, o servidor primário poderá reciclar segmentos de WAL antigos antes que o servidor em-espera os receba. Se isto ocorrer, o servidor em-espera precisará ser reinicializado a partir de uma nova cópia de segurança base. Isto pode ser evitado definindo wal_keep_size com um valor grande o suficiente para garantir que os segmentos de WAL não sejam reciclados muito cedo, ou configurando um encaixe de replicação para o servidor em-espera. Se for configurado um arquivamento de WAL acessível a partir do servidor em-espera, estas soluções não serão necessárias, porque o servidor em-espera sempre poderá usar o arquivamento para se recuperar, desde que sejam retidos segmentos suficientes.

Para usar a replicação por fluxo, deve ser configurado um servidor em-espera no modo de envio de registros de transação baseado em arquivo, conforme descrito em Servidores em-espera de envio de WAL. A etapa que transforma o servidor em-espera no modo de log-shipping baseado em arquivo em um servidor em-espera no modo de replicação por fluxo, é definindo a configuração de primary_conninfo para apontar para o servidor primário. Deve-se definir listen_addresses e as opções de autenticação (veja pg_hba.conf) no servidor primário, para que o servidor em-espera possa se conectar ao pseudo-banco de dados replication no servidor primário (veja Autenticação).

Em sistemas que oferecem suporte à opção de soquete keepalive, configurar tcp_keepalives_idle, tcp_keepalives_interval e tcp_keepalives_count ajuda o servidor primário perceber prontamente uma conexão interrompida.

Deve-se definir o número máximo de conexões simultâneas dos servidores em-espera (veja max_wal_senders para obter detalhes).

Quando o servidor em-espera é ativado, e primary_conninfo está definido corretamente, o servidor em-espera irá se conectar ao servidor primário após reproduzir todos os arquivos de WAL disponíveis no arquivamento. Se a conexão for estabelecida com sucesso, será visto um processo walreceiver no servidor em-espera, e um processo walsender correspondente no servidor primário.

# Permitir o usuário "foo" se conectar ao servidor primário a partir do
# hospedeiro com IP 192.168.1.100 para replicação, se a senha do usuário
# for fornecida corretamente.
#
# TYPE  DATABASE        USER        ADDRESS                 METHOD
host    replication     foo         192.168.1.100/32        scram-sha-256

# O servidor em-espera se conecta ao servidor primário em execução no
# hospedeiro 192.168.1.50 e na porta 5432, como o usuário "foo" cuja
# senha é "foopass".
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'

Os encaixes (slots) de replicação fornecem uma maneira automatizada de garantir que o servidor primário não remova segmentos de WAL até que tenham sido recebidos por todos os servidores em-espera, e que o servidor primário não remova linhas que possam causar conflito de restauração, mesmo quando o servidor em-espera estiver desconectado.

Em vez de usar encaixes de replicação, é possível impedir a remoção de segmentos do WAL antigos usando wal_keep_size, ou armazenando os segmentos no arquivamento usando archive_command ou archive_library. Uma desvantagem desses métodos é que eles frequentemente resultam na retenção de mais segmentos de WAL do que o necessário, enquanto os encaixes de replicação retêm apenas a quantidade de segmentos comprovadamente necessária.

Da mesma forma, hot_standby_feedback por si só, sem também usar encaixe de replicação, fornece proteção contra a remoção de linhas relevantes pelo processo de limpeza, mas não proporciona proteção durante qualquer período em que o servidor em-espera não esteja conectado.

postgres=# SELECT *
postgres-# FROM pg_create_physical_replication_slot('ponto_de_encaixe_a');

     slot_name      | lsn
--------------------+-----
 ponto_de_encaixe_a |
(1 linha)

postgres=# SELECT slot_name, slot_type, active
postgres-# FROM pg_replication_slots;

     slot_name      | slot_type | active
--------------------+-----------+--------
 ponto_de_encaixe_a | physical  | f
(1 linha)

primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
primary_slot_name = 'ponto_de_encaixe_a'

A funcionalidade de replicação em cascata permite que um servidor em-espera aceite conexões de replicação, e transmita registros de WAL para outros servidores em-espera, agindo como um retransmissor. Pode ser usado para reduzir o número de conexões diretas ao servidor primário, e também para minimizar as sobrecargas de largura de banda entre instalações.

Um servidor em-espera atuando tanto como receptor quanto como transmissor é conhecido como servidor em-espera em cascata. Os servidores em-espera que estejam mais diretamente conectados ao servidor primário são conhecidos como servidores upstream (rio acima/montante), enquanto os servidores em-espera mais distantes são os servidores downstream (rio abaixo/jusante). A replicação em cascata não impõe limites ao número ou a disposição dos servidores downstream, embora cada servidor em-espera se conecte a apenas um servidor upstream, que, por fim, se liga a um único servidor primário (nascente).

Um servidor em-espera em cascata envia não apenas os registros de WAL recebidos do servidor primário, mas também aqueles restaurados do arquivamento. Portanto, mesmo que seja fechada a conexão de replicação em alguma conexão upstream, a replicação por fluxo continuará downstream, enquanto novos registros de transação estiverem disponíveis.

No momento, a replicação em cascata é assíncrona. As configurações de replicação síncrona (veja Replicação síncrona) não têm efeito sobre a replicação em cascata no momento.

O retorno dos servidores Hot-Standby se propagam para os servidores upstream, independentemente da configuração em cascata

Se um servidor em-espera upstream for promovido para se tornar o novo servidor primário, os servidores downstream continuarão a transmitir do novo servidor primário, se recovery_target_timeline estiver definido como 'latest' (o padrão).

Para usar a replicação em cascata, deve-se configurar o servidor em-espera em cascata para poder aceitar conexões de replicação (ou seja, definir max_wal_senders e hot_standby, e configurar a autenticação baseada em hospedeiro). Também será necessário definir primary_conninfo no servidor em-espera downstream para apontar para o servidor em-espera em cascata.

A replicação por fluxo do PostgreSQL é assíncrona por padrão. Se o servidor primário falhar, algumas transações que foram efetivadas podem não ter sido replicadas para o servidor em-espera, causando perda de dados. A quantidade de dados perdidos é proporcional ao atraso da replicação no momento da comutação de servidores (failover).

A replicação síncrona oferece a capacidade de confirmar que todas as alterações feitas por uma transação foram transferidas para um ou mais servidores em-espera síncronos. Isto estende o nível padrão de durabilidade oferecido por uma efetivação de transação (commit). Na teoria da ciência da computação, este nível de proteção é referido como replicação 2-safe e group-1-safe (group-safe & 1-safe), quando synchronous_commit está definido como remote_write ^{[149] [150] [151] [152]}.

Ao requisitar a replicação síncrona, cada efetivação de uma transação de escrita aguardará até que seja recebida a confirmação de que a efetivação foi escrita nos registros de transação no disco do servidor primário e do servidor em-espera. A única possibilidade de perda de dados é se o servidor primário e o servidor em-espera sofrerem falhas ao mesmo tempo. Pode fornecer um nível muito mais alto de durabilidade, embora apenas se o administrador do sistema for cauteloso quanto ao posicionamento e gerenciamento dos dois servidores. Esperar pela confirmação aumenta a confiança do usuário de que as alterações não serão perdidas em caso de queda do servidor, mas também necessariamente aumenta o tempo de resposta para a transação solicitante. O tempo de espera mínimo é o tempo de ida e volta entre o servidor primário e servidor em-espera.

As transações de leitura-apenas, e a reversão de transações (rollback), não precisam esperar por respostas de servidores em-espera. As efetivações de subtransação não esperam por respostas de servidores em-espera, apenas as efetivações de nível superior esperam. As ações de execução longa, como carregamento de dados ou criação de índice, não esperam pela mensagem de efetivação final. Todas as ações de efetivação de duas-fases requerem esperas de confirmação, incluindo a preparação e a efetivação.

Um servidor em-espera síncrono pode ser um servidor em-espera de replicação física, ou um subscritor de replicação lógica. Também pode ser qualquer outro consumidor de fluxo de replicação de registros de transação físico ou lógico, que saiba como enviar as mensagens de retorno apropriadas. Além dos sistemas nativos de replicação física e lógica, também se incluem programas especiais como pg_receivewal e pg_recvlogical, bem como alguns sistemas de replicação de terceiros e programas personalizados. Deve ser verificada a respectiva documentação para obter detalhes sobre suporte à replicação síncrona.

synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'

synchronous_standby_names = 'ANY 2 (s1, s2, s3)'

Quando é usado o arquivamento contínuo de registros de transação no servidor em-espera, há dois cenários diferentes: o arquivamento de registros de transação pode ser compartilhado entre o servidor primário e o servidor em-espera, ou o servidor em-espera pode ter seu próprio arquivamento de WAL Se o servidor em-espera tiver seu próprio arquivamento de WAL, definir archive_mode como always, fará com que o servidor em-espera chame o comando de arquivamento para cada segmento de registro de transação que receber, seja por restauração do arquivamento, ou seja por replicação por fluxo. O arquivamento compartilhado pode ser gerido de forma semelhante ao não compartilhado, mas archive_command ou archive_library deve testar se o arquivo que está sendo arquivado já existe, e se o arquivo existente possui conteúdo idêntico. Isto requer mais atenção ao definir archive_command ou archive_library, porque deve tomar cuidado para não sobrescrever um arquivo existente com conteúdo diferente, e deve retornar sucesso se exatamente o mesmo arquivo for arquivado duas vezes. E tudo isto deverá ser feito livre de condições de concorrência, se dois servidores tentarem arquivar o mesmo arquivo ao mesmo tempo.

Se archive_mode estiver definido como on, o arquivador não será ativado durante a restauração ou no modo em-espera. Se o servidor em-espera for promovido, iniciará o arquivamento após a promoção, mas não arquivará nenhum arquivo de registros de transação ou histórico da linha do tempo que não tenha sido gerado por ele mesmo. Para obter uma série completa de arquivos de registro de transação no arquivamento, deve-se garantir que todos os registros de transação estejam arquivados, antes que cheguem ao servidor em-espera. Isto é inerentemente verdadeiro com o envio de registro de transação baseado em arquivamento, porque o servidor em-espera só pode restaurar arquivos encontrados no arquivamento, mas não se estiver ativada a replicação por fluxo. Quando o servidor não está no modo de restauração, não há diferença entre os modos on e always.