On 25-10-2011 10:04, Leonardo Carneiro wrote:
> Executei a seguinte sequencia de passos:
>
> 1) Configurei o archive no master e replication no master
> #WRITE AHEAD LOG
> wal_level = hot_standby
> wal_sync_method = fsync
> checkpoint_segments = 30
> archive_mode = on
> archive_command = 'ssh postgresql@[host] test ! -f
> /home/postgresql/remote_logs/%f && scp -C %p
> postgresql@[host]:~/remote_logs/%f'
> # REPLICATION
> max_wal_senders = 1
> wal_keep_segments = 20
>
Você não precisa fazer duas conexões ssh no archive_command; utilize somente o
último comando.
> 4) Fiz um tarball do cluster no master
>
Como você copiou? Você não precisa copiar pg_xlog/* pg_log/* e postmaster.pid.
> 7) Configurei o postgresql.conf no cluster slave com os seguintes parâmetros
> # WRITE AHEAD LOG
> wal_level = hot_standby
> wal_sync_method = fsync
> checkpoint_segments = 30
> # REPLICATION
> hot_standby = on
>
wal_level = minimal é suficiente; a menos que queira um dia promover o
servidor secundário a primário.
> 9) Movi o conteudo dp pg_xlog do slave para a pasta de recovery, sem
> sobreescrever eventuais arquivos já existentes
> bash $ mv -i $PGDATA/pg_xlog/0000000* /home/postgresql/remote_logs/
Não faça isso. Os arquivos necessários pelo servidor secundário já estão no
/home/postgresql/remote_logs.
> bash $ rm -rf $PGDATA/pg_xlog/*
Não se esqueça de remover o postmaster.pid e o conteúdo do diretório pg_log.
Como você não está utilizando streaming replication, sugiro que configure o
parâmetro archive_timeout para que o servidor secundário não passe longos
períodos defasados do servidor principal quando a atividade do banco de dados
estiver baixa.
--
Euler Taveira de Oliveira - Timbira http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
