Olá, estou seguindo este tutorial sempre que preciso configurar uma replicação binária, na verdade estou usando o segundo método chamado: "Iniciando a replicação com apenas uma reinicialização rápida do mestre" encontrado aqui: https://wiki.postgresql.org /wiki/Binary_Replication_Tutorial
Isso funciona bem.
Em um ambiente de teste, tentei usar tar em vez deste rsync:
rsync -av --exclude pg_xlog --exclude postgresql.conf --exclude postgresql.pid \
data/* 192.168.0.2:/var/lib/postgresql/data/
Assim:
tar -cz data >data.tar.gz
Gerar o arquivo .tar com os dados e descompactá-lo no slave, quão ruim isso pode ser para o banco de dados?
Nos logs, o escravo mostra que se conectou com sucesso ao mestre.
Supondo que o diretório de dados de replicação esteja começando vazio (o que deveria estar, ou você provavelmente está fazendo algo errado), esses comandos são basicamente equivalentes. Ambos leem todos os dados e fazem algo com eles.
O tar vai usar um pouco mais de CPU no servidor, porque estará rodando gzip, que provavelmente irá maximizar uma CPU, desde que haja uma livre. Ele também consumirá um pouco mais de capacidade de E/S, porque gravará o arquivo .tgz no disco em vez de transmitir diretamente pela rede (mas você pode alterar o comando tar para transmitir por ssh)
Nenhum desses deve fazer muita diferença, a menos que você já esteja no limite.
Considerando seu comentário sobre o quanto o rsync é mais lento: acho o rsync um pouco mais lento, mas não drasticamente. Eu me pergunto se você tem uma implementação disfuncional disso. Já ouvi falar (vagamente) de versões do rsync que interagem com versões do kernel do Linux de uma forma que causa tempestades de troca de contexto. De qualquer forma, se o tar for muito mais rápido, naturalmente imporá uma carga de IO mais alta no servidor, pois obtém todos os dados lidos em menos tempo, isso pode interferir na operação do servidor enquanto ocorre. Por outro lado, o que quer que o rsync esteja fazendo que o torne lento também pode estar consumindo recursos que o banco de dados gostaria de usar.
Infelizmente, quando você chega aos problemas de implementações de uma ferramenta que interage com as versões do kernel, etc., você tem um problema que só pode ser resolvido experimentalmente.
Se você está preocupado com a exatidão, tanto o rsync (quando usado como você mostra e em um diretório de destino vazio ) quanto o tar devem preservar a integridade de seus dados, é apenas uma questão de qual deles tem melhor desempenho e causa o menor impacto no desempenho na produção servidor, competindo com ele por recursos. Eu prefiro tar, porque o rsync convida as pessoas a tentar fazer coisas inteligentes que colocam seus dados em risco.