Existem algumas coisas erradas aqui.
Script do WAL
Tenta empurrar para cada servidor até que todos tenham sucesso
Primeiro, o seu servidor master está - ou está tentando - enviar os arquivos WAL para cada réplica, e somente trata o archive_command como bem-sucedido se todos os três receberem o arquivo. Isso significa que, se uma cair, as outras duas deixarão de receber uma nova WAL, porque a Pg no mestre ficará presa repetindo o mesmo segmento repetidamente.
Não percebe quando falha
Seu script não retorna realmente $FAIL , então, na prática, isso não funciona - ele reporta sucesso mesmo que todos os três servidores não recebam os arquivos WAL. Ele continuará se esforçando para o arquivo WAL, ignorando o fato de que uma falha anterior significa que toda a sequência é inútil e não pode ser repetida. Isso pode muito bem explicar por que as réplicas não conseguem encontrar os segmentos locais do WAL; eles provavelmente não conseguiram copiar devido a problemas de env-var ( RSYNC_RSH ), problemas de hosts conhecidos, problemas de chaves ssh, etc.
Como corrigir o script wal sender
Eu recomendo strongmente que você mude para um modelo push / pull. Ter o servidor mestre empurrar o WAL para um local de armazenamento confiável. Em seguida, faça as réplicas puxarem desse local. O mestre só tem que copiar o arquivo uma vez, e não precisa se preocupar em tentar novamente em pontos diferentes para servidores diferentes se alguns estiverem inativos, outros estão alcançando, etc. Uma escolha cada vez mais popular para isso é o Amazon S3, embora o Windows Azure O Block Service (WABS) e o OpenStack's Swift também são úteis. Uma ferramenta útil para isso é WAL-E , que pode servir como archive_command e restore_command ; suporta todas as lojas listadas.
Se você usar o S3, você pode ter uma política de arquivamento que armazene coisas antigas no Glacier em vez de removê-las e, em seguida, as exclua muito mais tarde. Esta é uma maneira barata e conveniente de armazenar coisas como esta "apenas no caso" - mas lembre-se, é inútil, a menos que você também armazene o backup básico associado!
Se você precisar ter o push mestre para todos os três back-ends, precisará ser muito mais inteligente, com um script que controla separadamente quais servidores receberam cada segmento do WAL e reporta sucesso quando um servidor recebeu um segmento e todos os segmentos anteriores . Você precisará de um trabalho em segundo plano que continue tentando os servidores que estão atrasados. Mesmo assim, esta é uma má ideia; Isso tornará seu arquivamento WAL tão lento quanto o servidor mais lento, o que realmente não é ideal e pode deixar o mestre preenchendo muito mal. Tenho certeza de que isso pode funcionar, mas a IMO é muito frágil e complicada.
A replicação de streaming está quebrada - o bug de renegociação SSLv3?
Nos seus registros:
2014-01-26 23:03:36 GMT FATAL: could not receive data from WAL stream: SSL error: sslv3 alert unexpected message
Seus servidores estão configurados para replicação de streaming, mas estão com problemas de SSL. Este é o erro de assinatura do problema de renegociação do sslv3, e o primeiro "reparo" do OpenSSL com morte cerebral para ele. Certifique-se de ter atualizado para a versão de patch mais recente do OpenSSL, pois isso deve resolver o problema.
Se isso não funcionar, você pode tentar ssl_renegotiation_limit=0 in postgresql.conf . Veja este bug da barra de lançamento .