Contexto:
Digamos que, ao usar Streaming Replication/Hot Standby em um cluster Postgres 9.1, um nó de standby fica inativo. Ele permanece inativo por um dia, durante o qual ocorre uma grande quantidade de DML no mestre. O recovery.conf do standby não contém uma entrada 'restore_command' (para restauração de arquivos de diário WAL), mas contém uma string 'primary_conninfo' (para replicação de streaming).
Pergunta:
Se eu iniciar o modo de espera novamente após um dia de alterações no mestre. Ele irá "recuperar o atraso" (eventualmente entrará em um estado que espelha o mestre) usando apenas a replicação de streaming? Ou devo habilitar o arquivamento de arquivos WAL e deixá-lo aplicar os arquivos arquivados durante a interrupção para garantir a moeda?
Eu verifiquei o documento de arquivamento/replicação de streaming do WAL aqui e ele diz que você não precisa habilitar o arquivamento do WAL e a replicação de streaming, mas não está claro se o catch-up acontecerá ou não sem o arquivamento do arquivo WAL ativado.
Obrigado!
Sim, ele irá recuperar, usando apenas streaming, se (e somente se) , o número de segmentos WAL gerados desde a última atualização no standby for menor que o valor de wal_keep_segments no postgresql.conf. Isso é abordado nesta seção da documentação: Replicação
no nó de espera, você pode definir restore_command em recovery.conf e, em seguida, copiar arquivos mestres pg_xlog (que faltam em espera) para a pasta que pontos de restore_command. Você pode encontrar facilmente quais arquivos xlog estão faltando iniciando o nó de inicialização e digitando
você verá lá "aguardando 000000020000005200000025" ou algo assim, que informa qual pg_xlog você deve começar a copiar do mestre para o caminho restore_command do modo de espera.
se você ativar o wal_archiving, ele iniciará o arquivo a partir do momento em que você o configurar.
Não, configurei uma instância de replicação de streaming e ela saiu de sincronia de alguma forma, não consegui fazê-la funcionar novamente até fazer um manual
rsync
dos arquivos WAL.