> Master: > SO: Ubuntu Desktop 11.10 x86 > PostgreSQL: 9.1.1, compilado direto do fonte > Slave > SO: Ubuntu Server 11.10 x86_64 > PostgreSQL: 9.1.1, compilado direto do fonte > Minha (tentativa de) replicação está sendo feita via WAN, usando apenas log > shipping no momento (não estou usando streaming replication). Já é possível > ver pelo cenário que eu cometi um erro ao escolher as arquiteturas. Enquanto
É, cometeu. Você ainda pode compilar o Slave em 32 bits pra não ter que reinstalar nenhum dos S.Os. > ainda estou trabalhando nisso, tenho algumas dúvidas quanto ao envio dos > logs, e também sobre o streaming, caso venho a usar. Minha base em produção > tem uma carga de escrita razoavel, escrevendo cerca de 140 arquivos de log > por hora. Fazendo a matemática básica, eu teria de ter um link de pelo menos > 6,5Mbps para manter a o slave atual em relação ao master. Meu objetivo é > reduzir esse número. Seu banco escreve em torno de 5 arquivos WAL / 5 min de checkpoint. > Dúvida 1: Envio do log > A documentação do Postgres fornece um exemplo (http://goo.gl/gyjnA) usando > os comandos 'test' e 'cp' para o envio dos logs. Como estou fazendo através > da WAN, estou usando 'scp' com troca de chaves, ao invés de 'cp'. Existe > algum problema em usar um comando compactando o arquivo, para diminuir o > volume de dados no link? Algo como: > > tar cjf - %p | ssh remotehost " ( cd /destination/path ; tar xjf - ) " Você pode colocar num script também. Não há problema lógico algum, só que você terá que fazer o inverso no Slave pra descompactar. Note que a compactação por gzip consome um bocado de CPU e pode interferir com sua operação normal de SGBD. Você pode também fazer um túnel ssh com compactação. O resultado será similar e a complexidade reduzida. Você também pode trocar o scp por rsync com a opção -z. É o mesmíssimo resultado e é o que eu costumo usar em produção. > Dúvida 2: Envio do banco para sincronização inicial > Como não estou configurando streaming replication no momento, não estou Por que não quer usar streaming replication? É tão mais simples... > usando o pg_basebackup para enviar o banco. Estou usando o comando SELECT > pg_start_backup('sync_inicial'); Realizo uma cópia com 'cp -a' e uso o > comando SELECT pg_stop_backup(); para voltar a operação normal. Como nesse Você terá de usar scp ou rsync né? O servidor slave é remoto. Ou você fará isso num passo a parte? > momento, os logs já estão sendo enviados, não vou perder nada de dados, > mesmo que demore um pouco para enviar o banco após enviar o comando 'stop'. > Existe problema em enviar os dados de maneira compactada, como na dúvida > anterior? Não há problema lógico algum. Atente para o consumo de CPU da compactação. Já vi gente sentar servidor de produção por esse descuido. Ou use uma máquina intermediária que faça esse trabalho. > Dúvida 3: Envio via streaming > O streaming, tanto para o envio do basebackup quanto para envio dos logs, > usa algum tipo de compactação? Se sim, isso é configurável de alguma > maneira? Eu não tenho a necessidade de manter meu slave 100% sincronizado em > tempo real em relação ao master, então a janela de tempo que o log shipping > tem em relação ao streaming replication não seria um ponto tão negativo, > caso não seja possível compactar o tráfego do streaming. Em testes, os > arquivos de logs compactados usando bz2 consomem cerca de 20% do tamanho > total descompactado. Nativamente não há compactação. Use um túnel ssh com opção -X para ele compactar os dados on-the-fly, ou alguma estratégia de VPN com compactação. []s Flavio Gurgel _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
