e Stream Replication (Prontidão a Quente e Fluxo de Replicação), neste artigo irei descrever como configurar três servidores com IPs
distintos e com Linux Slackware 13 rodando o Postgres 9.0 replicado, sendo 1 Master como escrita e leitura e 2 Slaves (replicado)
apenas com leitura, mas podendo ser executados consultas.
Se você usa o pgAdmin III atualize para versão 1.12.0 ou superior, pois o acesso ao Postgres 9.0 com este client só é possível a partir
desta versão.
Se não tiver servidores com fartura, ou um cluster para testar, você pode simular as máquinas com IPs distintos na rede, usei o Oracle
Virtual Box versão 3.2.6 com as placas de redes configuradas para modo bridge, não esqueça de adaptar os seus IPs conforme a estrutura
da sua rede.
Iremos instalar o Postgres 9.0, mais exatamente a versão 9.0.5, tomando por base o código fonte, isto é, iremos baixar, desempacotar e
compilar e instalar e depois configurar.
No servidor Master (ip: 10.3.128.1):
Baixar o Postgres 9.0 na pasta logado com usuário root:
#/usr/local #wget http://ftp.postgresql.org/pub/source/v9.0.5/postgresql-9.0.5.tar.gz Em seguida ainda logado com o usuário root: #cd /usr/local #cp /root/postgresql-9.0.5.tar.gz . #tar -zxvf postgresql-9.0.5.tar.gz #cd postgresql-9.0.5 #./configure #gmake #su #gmake install #adduser postgres #mkdir /usr/local/pgsql/data #chown postgres /usr/local/pgsql/data $su – postgres $/usr/local/pgsql/bin/initdb –D /usr/local/pgsql/data $/usr/local/pgsql/bin/postgres –D /usr/local/pgsql/data >logfile 2>&1 & $/usr/local/pgsql/bin/createdb test $/usr/local/pgsql/bin/psql test $exit
Nos servidores Slaves (ip: 10.3.128.2 e ip:10.3.128.3):
Mesmo terêtêtê do Master descrito anteriormente...
Até aqui foi instalado o Postgres no modo padrão nas três máquinas, porem ainda faltam alguns detalhes como arquivo padrão de inicialização,
habilitar o Linux ao reiniciar carregando o Postgres automaticamente, para isso iremos executar os comandos abaixo nas três máquinas servidoras:
#cp /usr/local/postgresql-9.0.5/contrib/start-scripts/linux /etc/rc.d/rc.pgsqld #chmod 755 /etc/rc.d/rc.pgsqld #./etc/rc.d/rc.pgsqld stop #./etc/rc.d/rc.pgsqld start #echo " # Start the PostgreSQL database: if [ -x /etc/rc.d/rc.pgsqld ]; then . /etc/rc.d/rc.pgsqld start fi " >> rc.M #reboot
Instalamos o Postgres em sua forma básica no Linux com a porta padrão 5432, nos três servidores, agora vamos configurar uma pasta compartilhada
NFS (Network File System) na máquina MASTER para que os SLAVES copiem WAL LOG desta pasta, não levei em consideração a segurança, na configuração
do NFS, mas você pode logo que usar essa receita de bolo, fazer uma ajuste fino no NFS, para tanto basta pedir uma ajudinha ao Google,
digitando: segurança nfs
Criando a pasta para replicação na máquina MASTER:
#mkdir /home/postgres/replication #chown postgres /home/postgres/replication
Configurando o NFS:
No servidor Master (ip: 10.3.128.1)
#echo " /home/postgres/replication 10.3.128.1(rw,subtree_check,no_root_squash,sync) /home/postgres/replication 10.3.128.2(rw,subtree_check,no_root_squash,sync) /home/postgres/replication 10.3.128.3(rw,subtree_check,no_root_squash,sync) " >> /etc/exports #echo " ALL: ALL@ALL " >> /etc/hosts.deny #echo " ALL : ALL@10.3.128.2 : ALLOW ALL : ALL@10.3.128.3 : ALLOW " >> /etc/hosts.allow #chmod 755 /etc/rc.d/rc.rpc #chmod 755 /etc/rc.d/rc.nfsd #. /etc/rc.d/rc.rpc start #. /etc/rc.d/rc.nfsd start #exportfs -a #rpcinfo –p #showmount –e localhost #mkdir /mnt/postgres #mount –t nfs 10.3.128.1:/home/postgres/replication /mnt/postgres #mount
Nos servidores Slaves (ip: 10.3.128.2 e ip:10.3.128.3):
#chmod 755 /etc/rc.d/rc.rpc #chmod 755 /etc/rc.d/rc.nfsd #. /etc/rc.d/rc.rpc start #. /etc/rc.d/rc.nfsd start #rpcinfo –p #showmount –e 10.3.128.1 #mkdir /mnt/postgres #mount –t nfs 10.3.128.1:/home/postgres/replication /mnt/postgres
Pronto até aqui configuramos o NFS para que os SLAVES copiem WAL-LOG do MASTER; agora iremos realmente fazer a replicação.
No servidor Master (ip: 10.3.128.1): (por segurança vamos fazer uma cópia de postgresql.conf e pg_hba.conf)
#cp /usr/local/pgsql/data/postgresql.conf /usr/local/pgsql/data/postgresql.conf.backup #cp /usr/local/pgsql/data/pg_hba.conf /usr/local/pgsql/data/pg_hba.conf.backup #echo " listen_addresses = '*' port = 5432 wal_level = hot_standby archive_mode = on archive_command = 'cp %p /home/postgres/replication/%f' max_wal_senders = 2 #wal_sender_delay = 200ms wal_keep_segments = 20 " >> /usr/local/pgsql/data/postgresql.conf #echo " host replication all 0.0.0.0/0 trust " >> /usr/local/pgsql/data/pg_hba.conf #. /etc/rc.d/rc.pgsqld restart
Alguns comentários sobre o terêtêtê acima:
No postgresql.conf:
Os parâmetros: listem_address = '*' , port = 5432 habilitam qualquer maquina externa acessar com a porta mencionada.
O parâmetro: wal_level = hot_standby habilita a servidor para replicação, Master.
O parâmetro: max_wal_senders = 2 habilita dois servidores Slaves a conectarem ao Master.
O parâmetro: archive_command = 'cp %p /home/postgres/replication/%f' copia os arquivos WAL-LOG, para um diretório distinto.
O parâmetro: #wal_sender_delay = 200ms define o interervalo entre as operações de envio de fragamentos (stream)
pelo processo WALSENDER. Padrão: 200 ms.
O parâmetro: wal_keep_segments = 20 define número de arquivos de log que devem ser mantidos para recuperação em caso de problemas
com restauração automática
No arquivo pg_hba.conf:
O parâmetro: host replication all 0.0.0.0/0 trust habilita qualquer máquina a acessar o master para replicação,
isso pode ser restringido para apenas os ips dos Slaves.
Se tudo ocorreu bem, o servidor Master (ip: 10.3.128.1) com banco test está em condições de acesso, use o seguinte comando:
#/usr/local/bin/psql –d test
Outra forma de monitorar, o que está acontecendo com servidor Master é vendo os logs de Postgres, conforme exemplo abaixo:
#tail –f /usr/local/pgsql/data/serverlog
No servidor Master (ip: 10.3.128.1)
Iniciando o backup do Master para os para os Slaves...
usr/local/data/pgsql/bin/psql –d postgres -c "SELECT pg_start_backup('ok');"
Nos servidores Slaves (ip: 10.3.128.2 e ip:10.3.128.3):
Copiando o diretório data do servidor Master para os Slaves e removendo o pg_xlog (WAL-LOG) e o arquivo postmaster.pid dos Slaves
#scp 10.3.128.1:/usr/local/pgsql/data/* /usr/local/pgsql/data #rm -f /usr/local/pgsql/data/pg_xlog/* #rm /usr/local/pgsql/data/postmaster.pid
Como copiamos o diretório data do Master para os Slaves, vamos pegar o backup postgresql.conf.backup e pg_hba.conf.backup
feito anteriormente no Master e aproveitar nos Slaves:
Ainda nos servidores Slaves (ip: 10.3.128.2 e ip:10.3.128.3) com instancias paradas do Postgres:
#cp /usr/local/pgsql/data/postgresql.conf.backup /usr/local/pgsql/data/postgresql.conf #cp /usr/local/pgsql/data/pg_hba.conf.backup /usr/local/pgsql/data/pg_hba.conf #echo " listen_addresses = '*' port = 5432 wal_level = minimal archive_mode = off hot_standby = on " >> /usr/local/pgsql/data/postgresql.conf #echo " standby_mode = 'on' primary_conninfo = 'host=10.3.128.1 port=5432 user=postgres password=postgres' restore_command = 'cp /mnt/postgres/%f %p' trigger_file = '/tmp/trigger.pgsql.5432' " > /usr/local/pgsql/data/recovery.conf #. /etc/rc.d/rc.pgsqld restart
O parâmetro: trigger_file = '/tmp/trigger.pgsql.5432' é apenas um arquivo vazio que diz que é um servidor standby, isto é,
slave (read-only), daí nome trigger_file (arquivo_gatilho).
No servidor Master (ip: 10.3.128.1)
Concluindo o backup do Master para os Slaves...
usr/local/data/pgsql/bin/psql -d postgres -c "SELECT pg_stop_backup();"
Neste momento o Master estará em modo read-write (escrita e leitura) e os Slaves sicronizados podendo fazer consultas;
estarão em modo read-only (somente-leitura).
Monitoramento da Replicação:
Via Query: (Com o pgAdmin III)
--Informações sobre o servidor standby (slave) --ultimo fragmento recebido do servidor de producao SELECT * FROM pg_last_xlog_receive_location() ; --ultimo fragmento aplicado durante a recuperacao --valores idênticos para as duas funções indicam que não há informações pendentes a serem aplicadas SELECT * FROM pg_last_xlog_replay_location() ; --indica se o servidor Postgres está em restauração SELECT * FROM pg_is_in_recovery() ;
Via Shell: (pg_controldata)
O aplicativo pg_controldata exibe varias informações de controle do WAL, a ser executado no shell,
para comparação entre o Master e os Slaves.
#./pg_controldata
Via Shell: (ps –efH | grep postgres)
ps –efH | grep postgres
No servidor de produção (master) é criado um processo WALSENDER para enviar os fragmentos do streaming replication
No servidor de standby (slave) é criado um processo WALRECEIVER para receber os fragmentos do streaming replication
Via Shell: (tail –f /usr/local/pgsql/data/serverlog)
No servidores é possível identificar muitos problemas ocasionados durante a replicação apenas visualizando o serverlog do Postgres.
#tail –f /usr/local/pgsql/data/serverlog
Algumas Considerações Importantes:
Consultas em servidores Slaves podem causar conflitos com operações de restauração que ocorrem em paralelo com o Master
Exemplo:
Uma operação de VACCUM FULL ao ser replicada pode remover um registro "morto" que esteja sendo utilizada por uma operação read-only.
Ao remover o registro a consulta poder trazer resultados incorretos.
Há duas maneiras de resolver esse problema:
Forma 1:
Parar a replicação até que a consulta finalize. (configurar no postgresql.conf do Master)
max_standby_delay = -1
Aguardam finalização das transações que causam conflito no servidores Slaves.
Ideal para ambientes onde as consultas são mais importantes que a sincronização dos servidores.
Forma 2:
Matar a(s) consulta(s) no(s) servidor(es) Slaves. (configurar no postgresql.conf do Master)
max_standby_delay = 0
Mata as consultas que estão causando conflito imediatamente.
Ideal para ambientes onde a sincronização é mais importante do que as consultas no servidores Slaves.
O Stream Replication isoladamente não disponibiliza servidor para consulta, apenas sincroniza os servidores
com os fragmentos (stream) dos logs de transação (WAL-LOG).
Algumas Dicas:
Recomendo para não consumir o link de banda, isto é a replicação não competir com o uso tradicional de servidor Master,
utilizar uma placa de rede adicional 10 Gigabits Ethernet, ou superior.
Automatizar o processo de failover usando Hearbeat.
Utilizar ferramentas para balanceamento de carga de consultas.
E concluindo o PostgreSQL 9.0 não contempla a Replicação Síncrona e a Replicação em Cascata,
mas há boas pespectivas futuras de que o PostgreSQL 9.1 venha a ser lançado com esses recursos,
além de um sistema de backup baseado no Streaming Replication.
Referencia:
http://www.postgresql.org
http://www.postgresql.org.br
http://planeta.postgresql.org.br/
http://blog.softa.com.br/
http://www.dextra.com.br
http://emersonhermann.blogspot.com