Em 30 de junho de 2011 16:12, André Ormenese <[email protected]> escreveu:
> > > Em 30 de junho de 2011 14:58, André Ormenese <[email protected]>escreveu: > > >> >> Em 30 de junho de 2011 12:37, Euler Taveira de Oliveira < >> [email protected]> escreveu: >> >> Em 30-06-2011 11:15, Flavio Henrique Araque Gurgel escreveu: >>> > Deveria ter um subdiretório archive_status aí >>> > >>> Se não tiver o PostgreSQL cria. >>> >>> Voltando ao assunto, você não disse como fez a cópia de segurança física. >>> Além >>> disso, não entendi porque você está arquivando os logs de transação no >>> servidor secundário. Vide [1] para uma explicação do processo de >>> replicação >>> por fluxo. Apresente as configurações do servidor primário e secundário >>> novamente e os logs do servidor secundário para tentarmos identificar o >>> problema. >>> >>> >>> [1] >>> http://eulerto.blogspot.com/2010/11/hot-standby-e-streaming-replication.html >>> >>> >>> -- >>> Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/ >>> PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento >>> >>> Euler, >> Fiz a cópia física utilizando tar e scp para enviar ao slave, após >> executar o pg_start_backup, e depois do tar, o pg_stop_backup. >> >> Estou copiando os logs de transação no secundário, pois, por falta de >> conhecimento, achei que estes aqruivos eram necessários para o slave, qdo >> startado, fazia o recover utilizando todos estes arquivos, e só depois dessa >> atualização começava a fazer a replicação. >> >> Segue abaixo as configurações do master e slave : >> >> *Minhas configurações no master :* >> >> *Postgresql.conf* >> >> wal_level = hot_standby >> archive_mode = on >> archive_command = 'test ! -f /dados/wal/hemo/"%f" && cp "%p" >> /dados/wal/hemo/"%f"' >> >> # - Streaming Replication - >> >> max_wal_senders = 2 >> wal_sender_delay = 200ms >> wal_keep_segments = 10 >> >> *pg_hba.conf * >> * >> * >> #Streming replication : esta linha serve para conexao com o slave >> host replication all 10.0.0.1/32 trust >> >> *Minhas configurações no slave :* >> * >> * >> *Postgresql.conf* >> wal_level = archive >> archive_mode = on >> archive_command = 'test ! -f /dados/wal/hemostigma/"%f" && cp "%p" >> /dados/wal/hemostigma/"%f"' >> >> # - Standby Servers - >> >> hot_standby = on * >> >> * >> max_standby_archive_delay = 30s >> max_standby_streaming_delay = 5s >> >> *recovery.conf* >> restore_command = 'cp /dados/wal/hemo/%f %p' >> >> standby_mode = 'true' >> >> primary_conninfo = 'host=10.0.0.2 port=5437 user=postgres >> password=xxxxxxxxxxx' >> >> trigger_file = '/tmp/trigger_pg901_5437' >> >> >> Este é log do slave no start : >> LOG: database system was interrupted; last known up at 2011-06-28 >> 09:12:39 BRT >> LOG: restored log file "00000002.history" from archive >> LOG: entering standby mode >> LOG: restored log file "0000000200000004000000A7" from archive >> LOG: redo starts at 4/A7000020 >> LOG: restored log file "0000000200000004000000A8" from archive >> LOG: record with zero length at 4/A885BFE0 >> LOG: streaming replication successfully connected to primary >> >> >> Posso então retirar o restore_command do recovery.conf, e desabilitar o >> envio dos logs de transação do master p/ o slave ??? >> >> Obrigado >> André >> > > > Fiz o que relatei acima !!! > Mas o problema persiste..... > > Segue log do slave : > LOG: database system was interrupted; last known up at 2011-06-29 17:39:16 > BRT > LOG: entering standby mode > LOG: streaming replication successfully connected to primary > LOG: redo starts at 4/AD0000B0 > > e fica parado neste ponto !!! > > > > Pessoal, mais um capítulo .... observei no link que o Euler enviou que o número apresentado pelo pg_start_backup no master, é o mesmo do redo starts no log do slave. postgres=# select pg_start_backup('replicacao', true); pg_start_backup -----------------*0/5044CB4* (1 row) LOG: database system was interrupted; last known up at 2010-11-14 14:08:19 BRT LOG: entering standby mode LOG: *redo starts at 0/5044CB4* LOG: restartpoint starting: xlog LOG: consistent recovery state reached at 0/A000000 LOG: database system is ready to accept read only connections LOG: streaming replication successfully connected to primary Aqui não esta acontecendo a mesma coisa... isso pode ser a raiz do problema ???? hemocentro=# select pg_start_backup('hemo_30_06'); pg_start_backup ----------------- *4/B1000020* (1 row) LOG: database system was interrupted; last known up at 2011-06-30 16:23:16 BRT LOG: entering standby mode LOG: streaming replication successfully connected to primary LOG: *redo starts at 4/B10156F8*
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
