"Replicação de streaming" refere-se ao envio contínuo de registros WAL por uma conexão TCP / IP entre o mestre e a réplica, usando o protocolo walsender em replicationconexões. O mestre lê seu próprio WAL pg_xloge o envia para a réplica sob demanda. Ele é configurado com uma primary_conninfodiretiva recovery.confe pg_hba.confentradas no mestre para permitir replicationconexões. Você também precisa wal_keep_segmentse algumas outras opções abordadas nos documentos.
"Envio de log" refere-se ao envio periódico de registros WAL como arquivos WAL inteiros por meio de um protocolo de transferência de arquivos para um local de arquivo a partir do qual a réplica pode buscá-los. Está configurado com uma restore_commanddiretiva in recovery.confe uma archive_commandno master. O PostgreSQL não se importa onde os arquivos estão ou como são transferidos, apenas que os archive_commandcoloca ali e restore_commandbuscam o arquivo necessário; isso permite a construção de sistemas como PgBarman e WAL-E.
A replicação de streaming não tem tanto atraso, pois os registros são enviados e gerados. No entanto, exige que o mestre e a réplica estejam online e possam se comunicar diretamente. Também requer que a réplica mantenha-se bem o suficiente para que o mestre ainda tenha cópias em disco do WAL necessárias para a réplica, e geralmente exige que você gaste pg_xlogespaço extra na retenção de WAL extra para a réplica.
A replicação de envio de log tem mais atraso porque a réplica só vê o WAL quando um arquivo inteiro é enviado. No entanto, ele pode funcionar mesmo quando o mestre e a réplica não podem se comunicar diretamente por TCP / IP usando um local de armazenamento compartilhado. Ele continua funcionando mesmo que a réplica esteja inativa por um tempo, porque o mestre descartou o WAL pg_xlogsomente depois de arquivá-lo, portanto o WAL ainda está no arquivo morto e pode ser usado pela réplica, mesmo que o mestre não possa enviá-la. transmitindo mais. Observe que archive_commandnunca desiste; portanto, pg_xlogpode ser preenchido se o arquivamento falhar; por esse motivo, é melhor arquivar em um local confiável e fazer com que o servidor de réplica seja buscado nesse local.
Em geral, você realmente combina os dois, ou seja, usa os dois. Nesse caso, a replicação de streaming é usada quando tudo está indo bem. Se a réplica ficar muito atrasada e o mestre tiver descartado os xlogs necessários, surgir um problema de conectividade etc., a réplica passará para a leitura do WAL arquivado até que seja recuperada. Periodicamente, tentará voltar ao fluxo contínuo até obter êxito.
Se você usar apenas um, use o envio de logs, porque a replicação de streaming sem fallback de envio de logs é (até o PostgreSQL 9.4) potencialmente propensa ao atraso na replicação, causando falhas que forçam a reconstrução de uma réplica.
O PostgreSQL 9.4 muda um pouco isso, porque a replicação de streaming agora pode usar "slots de replicação". Isso permite que o mestre controle quanto WAL uma réplica precisa e evite jogá-la fora até que a réplica a reproduza. Portanto, não há mais necessidade wal_keep_segmentsse você usar um slot de replicação (não o padrão).
Veja meu artigo fazendo streaming de slots de replicação no PostgreSQL 9.4 .
9.4 também apresenta as bases para a replicação lógica de streaming , que é outro mecanismo, projetado para uso por sistemas de replicação lógica como Londiste, Slony-I e o novo recurso de replicação multimestre assíncrona bidirecional .