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 !!!
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
