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

Estou tentando entender os melhores usos da replicação do PostgreSQL e como ela funciona, para que eu possa solucionar problemas em um ambiente de produção.

Estou tendo dificuldade para entender as diferenças entre esses 2 tipos de replicação em termos de (1) Configuração (2) Como os 2 servidores Master / Slave se saem em cada cenário

A replicação no PostgreSQL (9.2+) é essencialmente arquivos XLOG de 16 MB de tamanho (dependendo das configurações de frequência para a criação de cada arquivo) estão sendo criados no Master e enviados por algum método ao escravo.

Minha configuração (para fins desta pergunta)

Configuração do Postgresql.conf no
arquivo mestre_command = 'rsync -av% p postgres @ [SlaveIP]: [wal_archive_folder] /% f'

Configuração do Recovery.conf no Slave para ler os arquivos de log
restore_command = 'cp [pasta_arquiva_do_arquivo] /% f \ "% p \"'
primary_conninfo = 'host = [MasterIP] port = 5432 user = postgres'

Minha pergunta é: que parte dessa configuração faz essa replicação de "streaming" versus "envio de logs"? Meu mestre está configurado para usar o rsync para enviar logs para o escravo (este log está sendo enviado?) Meu escravo está configurado para poder conectar-se ao mestre em recovery.conf (este streaming está sendo feito?)

Segunda parte da pergunta: O que está acontecendo? Entendo que existe outro protocolo no PostgreSQL via WAL_sender e WAL_receiver. Mas não sei se isso é usado apenas para streaming e, se sim, como o rsync está sendo usado no Master?

:) Obrigado!! E desculpe se esta é uma pergunta óbvia. Venho lendo bastante blogs / livros, mas tenho dificuldade em entender. O wiki do Postgres é tão profundo que leva muito tempo para passar por tudo (e eu tenho prazos)

"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 .