replicaçao postgres morna quase pelando

Voltamos!

E hoje num dia chuvoso nada melhor que escrever um tutorial
- Ta loko!
- Por que?
- Bom mesmo e´ se funcionar :)

depois de algumas pesquisas(google) de como fazer replicaçao com bando de dados
postgres chegamos a alguns resultados:

Com slony, ´e legal quando voce quer replicar determinadas partes do banco,
e tem o pgadmin que ajuda muito na configuracao. Contras nao replica
objetos largos. qualquer coisa que mexer no master ex. alterar tipo de campo, criar tabela
tem que fazer a mesma coisa no slave, o replicador nao faz automatico.

Com pgcluter precisa de no minimo tres maquinas, em algums casos com maquina virtual
vc coloca pra funcionar tudo na mesma maquina, mas dai nao tem vantagem :(

Ai foi que nosso amigo Edson (unimake), sugeriu o modo standby, no qual o slaver fica sendo atualizado
pelo master em um determinado tempo e no que precisa esta pronto para entrar em produçao.

Em busca de mais detalhes desse modo, descobrimos que existe o modo hot, e warm,
o hot o slave fica no ar e esta apto para consultas, no modo war o slave fica baixado

E com base nesse tutorial (http://www.gulbf.com.br/?q=node/33) estamos fornecendo um modo
de fazer isso.

O ambiente testado foi ubuntu e a versao do postgresql 8.3.

Para facilitar vamos utilizar simbolos para descrever onde o comando deve ser executado:
* na maquina master @
* na maquina slave #

- instalar o postgres:
# @ apt-get install postgresql

- instalar o rsync
# @ apt-get install rsync

- parar o banco
# invoke-rc.d postgresql-8.3 stop

- habilitar a conexao do ssh por chave publica
@ ssh-keygen

- copiar a chave publica para a slave
@ scp .ssh/id_rsa.pub root@192.168.1.x:/root/

- copiar o arquvio para .ssh/authorized_keys se nao existir
# cp /root/id_rsa.pub /root/.ssh/authorized_keys
- ou ediar se exister e colar o conteudo do id_rsa.pub para dentro
# vim .ssh/authorized_keys

- igualar o UID do usuario e do grupo postgres de ambas as maquinas

# vim /etc/group
# find / -group 109 -exec /bin/chown -v .125 {} \;
- onde o 109 era o uid antigo e 125 ´e o uid novo, caso for diferente o uid do slave em relacao ao master

# vim /etc/passwd
- lembrar de alterar o uid do group caso foi alterado acima
# find / -user 104 -exec /bin/chown -v 113 {} \;
- onde o 104 era o uid antigo e 113 ´e o uid novo, caso for diferente o uid do slave em relacao ao master

- mover o diretorio da instalacao e preparar um novo para recever os arquivo do master
# mv main/ main-old/
# mkdir main
# chown postgres:postgres main -R

Tudo pronto so sincronizar e rezar

@ /usr/bin/rsync -Cravzp /var/lib/postgresql/8.3/main/ root@192.168.1.x:/var/lib/postgresql/8.3/main/

Funciono? Graças a Deus?

agora so colocar um scrpt prar a cada intervalo sincronizar


#!/bin/bash
echo 'Iniciando sincronizacao de arquivos...'
/usr/bin/rsync -Cravzp /var/lib/postgresql/8.3/main/ root@192.168.1.x:/var/lib/postgresql/8.3/main/
echo 'Finalizado.'
echo 'Aguardando proxima sincronizacao...'
sleep 60
exec $(pwd)/replica.sh




Entao vou acrescentar mais algumas dicas como forma de melhoria do post

a primeira dela é simples, para poder configurar o rsync para poder conectar em uma porta diferente do ssh. Deve-se utilizar o parametro:
/usr/bin/rsync -Cravzp --rsh='ssh -p2220'

a segunda é tambem relacionada ao rsync. Em alguns casos o servidor slave pode executar o comando de sincronismo sem problemas, assim varias maquinas podem ser sincronizadas ou tambem, por algum motivo de segurança o servidor nao pode acessar o ssh do slave.

a terceira é importante! nao foi colocado nesse post mas é recomendavel habilitar os archives do postgres, assim se o db no master corromper, a replicação é repassada mas pelo logs da pra recuperar