PostgreSQL streaming versus replicação baseada em arquivo (em termos de comportamento e configuração do servidor)

"Replicação de streaming" refere-se ao envio contínuo de registros WAL por meio de uma conexão TCP/IP entre o mestre e a réplica, usando o protocolo walsender nas replicationconexões. O mestre lê seu próprio WAL pg_xloge o envia para a réplica sob demanda. É configurado com uma primary_conninfodiretiva in recovery.confe pg_hba.confentradas no mestre para permitir replicationconexões. Você também precisa wal_keep_segmentsde 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 arquivo para um local de arquivo do qual a réplica pode buscá-los. É configurado com uma restore_commanddiretiva in recovery.confe um archive_commandno master. O PostgreSQL não se importa onde os arquivos estão ou como eles são transferidos, apenas os archive_commandcoloca lá e restore_commandbusca 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 à medida que são gerados. No entanto, requer que o mestre e a réplica estejam online e possam se comunicar diretamente. Ele também requer que a réplica se mantenha bem o suficiente para que o mestre ainda tenha cópias em disco do WAL de que a réplica precisa e geralmente requer que você gaste pg_xlogespaço extra para reter o 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, 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 fora do ar por um tempo, pois o mestre terá descartado o WAL pg_xlogsomente após arquivá-lo, então o WAL ainda está no arquivo e utilizável pela réplica mesmo que o mestre não possa enviá-lo por streaming mais. Observe que archive_commandnunca desiste, portanto, pg_xlogpode preencher se o arquivamento estiver falhando; por esse motivo, é melhor arquivar em um local confiável e, em seguida, fazer com que o servidor de réplica busque 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 mudará para a leitura do WAL arquivado até que seja recuperada. Ele tentará periodicamente voltar ao streaming até conseguir.

Se você for usar apenas um, use o envio de log, porque a replicação de streaming sem fallback de envio de log é (até o PostgreSQL 9.4) potencialmente propenso a atrasos de replicação, causando falhas que forçam uma réplica a ser reconstruída.

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 acompanhe quanto WAL uma réplica precisa e evite jogá-lo fora até que a réplica o 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 streaming de slots de replicação no PostgreSQL 9.4 .

9.4 também apresenta as bases para replicação lógica de streaming , que é ainda 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 .