[pgbr-geral] Replicação nativa do postgresql 9.2 com problema

2013-07-11 Por tôpico Deliane Andrade 
Olá, boa tarde.

Pessoal, tenho um servidor master e um slave que estava trabalhando
normalmente com a replicação nativa.
Notei que quando o script de vacuum/backup entra em ação todo dia às 00:00h
a replicação é parada.
Tentei refazer o rsync ,mas quanto tento dar o start no slave o mesmo não
inicia o serviço do postgresql.

O log me informa o seguinte:

%%2013-07-11 15:23:49.902 BRTLOG:  sistema de banco de dados foi
interrompido; última execução em 2013-07-11 15:24:57 BRT
%%2013-07-11 15:23:49.903 BRTLOG:  entrando no modo em espera
%%2013-07-11 15:23:49.908 BRTLOG:  replicação em fluxo conectou-se com
sucesso ao servidor principal
%%2013-07-11 15:23:50.235 BRTLOG:  redo inicia em B72/3420
%%2013-07-11 15:23:50.236 BRTFATAL:  não pôde acessar status da
transação 65598726
%%2013-07-11 15:23:50.236 BRTDETALHE:  não pôde ler do arquivo
pg_clog/003E deslocado de 139264: Sucesso.
%%2013-07-11 15:23:50.236 BRTCONTEXTO:  redo do xlog commit: 2013-07-11
15:24:58.009033-03
%%2013-07-11 15:23:50.237 BRTLOG:  processo de inicialização (PID 1719)
terminou com código de retorno 1
%%2013-07-11 15:23:50.237 BRTLOG:  terminando quaisquer outros processos
servidor ativos
~


Resumindo, mesmo refazendo todo o processo  da forma abaixo :

MASTER :
postgres@condor:~$ psql

postgres@condor:~$ psql
psql (9.2.2)
Digite help para ajuda.

postgres=# select pg_start_backup('replicacao', true);

postgres=# \q

postgres@condor:~$ rsync -a -v -e ssh /dbprod/data/
postgres@192.168.200.45:/dbprod/data/
--exclude postmaster.pid --exclude postgresql.conf --exclude pg_hba.conf

postgres@condor:~$ psql

postgres@condor:~$ psql
psql (9.2.2)
Digite help para ajuda.

postgres=# select pg_stop_backup();


SLAVE :
root@cidadevelha:/dbprod/data/pg_log# /etc/init.d/postgres start
Starting PostgreSQL: ok

root@cidadevelha:/dbprod/data/pg_log# /etc/init.d/postgres status
pg_ctl: nenhum servidor está executando
root@cidadevelha:/dbprod/data/pg_log#

O meu SLAVE não sobe.
A mensagem do log a citada anteriormente.
Alguém teria idéia do que esteja acontecendo?

Agradeço a atenção.

Deliane Andrade
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql 9.2 com problema

2013-07-11 Por tôpico Flavio Henrique Araque Gurgel 

Em 11-07-2013 15:37, Deliane Andrade escreveu:

Olá, boa tarde.

Pessoal, tenho um servidor master e um slave que estava trabalhando
normalmente com a replicação nativa.
Notei que quando o script de vacuum/backup entra em ação todo dia às
00:00h a replicação é parada.


Qual a saída completa do comando:
SELECT version();

Verifique se seu PostgreSQL foi compilado com gcc 4.6.0 - tem um bug 
relacionado a isso. Como foi feita a instalação do seu PostgreSQL?



Tentei refazer o rsync ,mas quanto tento dar o start no slave o mesmo
não inicia o serviço do postgresql.

O log me informa o seguinte:

%%2013-07-11 15:23:49.902 BRTLOG:  sistema de banco de dados foi
interrompido; última execução em 2013-07-11 15:24:57 BRT
%%2013-07-11 15:23:49.903 BRTLOG:  entrando no modo em espera
%%2013-07-11 15:23:49.908 BRTLOG:  replicação em fluxo conectou-se
com sucesso ao servidor principal
%%2013-07-11 15:23:50.235 BRTLOG:  redo inicia em B72/3420
%%2013-07-11 15:23:50.236 BRTFATAL:  não pôde acessar status da
transação 65598726
%%2013-07-11 15:23:50.236 BRTDETALHE:  não pôde ler do arquivo
pg_clog/003E deslocado de 139264: Sucesso.
%%2013-07-11 15:23:50.236 BRTCONTEXTO:  redo do xlog commit:
2013-07-11 15:24:58.009033-03
%%2013-07-11 15:23:50.237 BRTLOG:  processo de inicialização (PID
1719) terminou com código de retorno 1
%%2013-07-11 15:23:50.237 BRTLOG:  terminando quaisquer outros
processos servidor ativos
~


Resumindo, mesmo refazendo todo o processo  da forma abaixo :

MASTER :
postgres@condor:~$ psql

postgres@condor:~$ psql
psql (9.2.2)


Esta é a versão só do psql ou do servidor também?
Verifique. Atualize imediatamente.


Digite help para ajuda.

postgres=# select pg_start_backup('replicacao', true);

postgres=# \q

postgres@condor:~$ rsync -a -v -e ssh /dbprod/data/
postgres@192.168.200.45:/dbprod/data/ --exclude postmaster.pid --exclude
postgresql.conf --exclude pg_hba.conf


Inclua --delete na sua linha de comando do rsync pra não ficar lotando o 
espaço no seu escravo.



postgres@condor:~$ psql

postgres@condor:~$ psql
psql (9.2.2)
Digite help para ajuda.

postgres=# select pg_stop_backup();


SLAVE :
root@cidadevelha:/dbprod/data/pg_log# /etc/init.d/postgres start
Starting PostgreSQL: ok

root@cidadevelha:/dbprod/data/pg_log# /etc/init.d/postgres status
pg_ctl: nenhum servidor está executando
root@cidadevelha:/dbprod/data/pg_log#

O meu SLAVE não sobe.
A mensagem do log a citada anteriormente.
Alguém teria idéia do que esteja acontecendo?


Pode ser o tal bug no gcc. Verifique a versão dele como recomendei mais 
acima.


Sua replicação está em modo síncrono? Se estiver, tente deixá-la 
assíncrona temporariamente e verifique se o problema se resolve.


Poste aqui por favor:
Como está seu recovery.conf.
Apenas as configurações de replicação do postgresql.conf do mestre 
(grupo Master Servers do arquivo).
Apenas as configurações de replicação do postgresql.conf do escravo 
(grupo Standby Servers do arquivo).


[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql 9.2 com problema

2013-07-11 Por tôpico Deliane Andrade 
Vamos lá!

Qual a saída completa do comando: SELECT version(); 
 postgres=# SELECT version();
   version
--
 PostgreSQL 9.2.2 on x86_64-unknown-linux-gnu, compiled by gcc (Debian
4.4.5-8) 4.4.5, 64-bit
(1 registro)

Verifique se seu PostgreSQL foi compilado com gcc 4.6.0 - tem um bug
relacionado a isso. Como foi feita a instalação do seu PostgreSQL? 

root@condor:/dbprod/data#  gcc --version
gcc (Debian 4.4.5-8) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


  Esta é a versão só do psql ou do servidor também?
 Verifique. Atualize imediatamente.


A versão do  Postgresql instalado é a 9.2.2 -- não posso trocar de versão
no momento,pois está em produção.


  Inclua --delete na sua linha de comando do rsync pra não ficar lotando o
 espaço no seu escravo.
  OK



  Pode ser o tal bug no gcc. Verifique a versão dele como recomendei mais
 acima.

 Sua replicação está em modo síncrono? Se estiver, tente deixá-la
 assíncrona temporariamente e verifique se o problema se resolve.


 Assíncrona.

Poste aqui por favor:
Como está seu recovery.conf.

 recovery.conf :


 standby_mode = 'on'
 primary_conninfo = 'host=*ip do master* port=5432 user=replicacao
 password=*senha*'
 trigger_file = '/local/script/failover.trg'



 Apenas as configurações de replicação do postgresql.conf do mestre (grupo
 Master Servers do arquivo).



#--
# REPLICATION
#--

# - Sending Server(s) -

# Set these on the master and on any standby that will send replication
data.

  # max number of walsender processes
max_wal_senders = 1
# (change requires restart)
# in logfile segments, 16MB
each; 0 disables
wal_keep_segments = 100

#replication_timeout = 60s  # in milliseconds; 0 disables

# - Master Server -

# These settings are ignored on a standby server.

#synchronous_standby_names = '' # standby servers that provide sync rep
# comma-separated list of application_name
# from standby(s); '*' = all
#vacuum_defer_cleanup_age = 0   # number of xacts by which cleanup is
delayed

# - Standby Servers -

# These settings are ignored on a master server.

#hot_standby = on   # on allows queries during
recovery
# (change requires restart)
#max_standby_archive_delay = 30s# max delay before canceling queries
# when reading WAL from archive;
# -1 allows indefinite delay
#max_standby_streaming_delay = 30s  # max delay before canceling queries
# when reading streaming WAL;
# -1 allows indefinite delay
#wal_receiver_status_interval = 10s # send replies at least this often
# 0 disables
#hot_standby_feedback = off # send info from standby to prevent
# query conflicts



 Apenas as configurações de replicação do postgresql.conf do escravo (grupo
 Standby Servers do arquivo).

 []s

 __**
 Flavio Henrique A. Gurgel
 Líder de Projetos Especiais
 Consultoria, Projetos  Treinamentos 4LINUX
 Tel1: +55-11.2125-4747 ou 2125-4748
 www.4linux.com.br
 email: fla...@4linux.com.br
 __
 FREE SOFTWARE SOLUTIONS
 __**_
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.**org.brpgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.**br/cgi-bin/mailman/listinfo/**pgbr-geralhttps://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql 9.2 com problema

2013-07-11 Por tôpico Deliane Andrade 
Desculpem faltou  um tópico:

Apenas as configurações de replicação do postgresql.conf do escravo (grupo
Standby Servers do arquivo).



#--
# REPLICATION
#--

# - Standby Servers -

# These settings are ignored on a master server.

hot_standby = on# on allows queries during
recovery
# (change requires restart)
#max_standby_archive_delay = 30s# max delay before canceling queries
# when reading WAL from archive;
# -1 allows indefinite delay
#max_standby_streaming_delay = 30s  # max delay before canceling queries
# when reading streaming WAL;
# -1 allows indefinite delay
#wal_receiver_status_interval = 10s # send replies at least this often
# 0 disables
#hot_standby_feedback = off # send info from standby to prevent
# query conflicts


Att,
 Deliane Andrade
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql 9.2 com problema

2013-07-11 Por tôpico Flavio Henrique Araque Gurgel 

Em 11-07-2013 16:22, Deliane Andrade escreveu:

Vamos lá!

Qual a saída completa do comando: SELECT version(); 
  postgres=# SELECT version();
version
--
  PostgreSQL 9.2.2 on x86_64-unknown-linux-gnu, compiled by gcc (Debian
4.4.5-8) 4.4.5, 64-bit
(1 registro)


Ok, GCC 4.4.5 não é afetado pelo bug.


Verifique se seu PostgreSQL foi compilado com gcc 4.6.0 - tem um bug
relacionado a isso. Como foi feita a instalação do seu PostgreSQL? 
 
root@condor:/dbprod/data#  gcc --version
gcc (Debian 4.4.5-8) 4.4.5


Esta é a versão do gcc em seu S.O. e não a que compilou o PostgreSQL 
(que está na saída do version, acima).




 Esta é a versão só do psql ou do servidor também?
Verifique. Atualize imediatamente.


A versão do  Postgresql instalado é a 9.2.2 -- não posso trocar de
versão no momento,pois está em produção.


Na próxima janela possível, atualize. Tem bugs graves!


 Inclua --delete na sua linha de comando do rsync pra não ficar
lotando o espaço no seu escravo.
  OK

  Assíncrona.


OK.

De acordo com:
http://www.postgresql.org/message-id/caa11fe2.1dde2%linas.virba...@continuent.com

Um colega que já passou por isso fez uma mudança de procedimento ao 
executar o início do backup, com:

SELECT pg_start_backup('nome', true);

E resolveu o problema.

É um caso de que alguns segmentos de log de transação faltaram pra 
tornar o backup válido. Com o true no comando, um checkpoint será 
forçado no início do backup, terminando o anterior imediatamente, ao 
invés de esperar. Isso torna a sequência de logs de transação 
necessários à restauração correta.


Teste e nos avise se deu certo, por favor.

[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql

2013-04-03 Por tôpico Flavio Henrique Araque Gurgel 

Em 03-04-2013 08:41, Deliane Andrade escreveu:

Bom dia.

Nada a ver com sua pergunta, mas, por que você faz esse procedimento,
ainda mais numa versão recente do PostgreSQL? 
Durante o dia há muitas operações de DELETE e UPDATE.


O autovacuum deveria tomar conta disso pra você. Mais simples, sem 
burocracia :)



Passe os logs do *escravo* por favor.

Aí vai o log do escravo.
Nos dois últimos dias se apresenta com as mesma mensagem.
Começou a aparecer esta mensagem após o script de  vacuum full analyze
que roda todo dia a 00:00 .
Acontece que após isso não tem replicado mais nada. :(

%%2013-04-02 23:59:56.071 BRTLOG:  replicação em fluxo conectou-se
com sucesso ao servidor principal
%%2013-04-02 23:59:56.071 BRTFATAL:  não pôde receber dados do fluxo
do WAL: FATAL:  segmento do WAL solicitado 000101B000E7 já
foi removido


%%2013-04-03 00:00:01.076 BRTLOG:  replicação em fluxo conectou-se
com sucesso ao servidor principal
%%2013-04-03 00:00:01.076 BRTFATAL:  não pôde receber dados do fluxo
do WAL: FATAL:  segmento do WAL solicitado 000101B000E7 já
foi removido


Considere então colocar um valor mais alto em wal_keep_segments.
Comece com 30, se ainda acontecer vá pra 100.


  
Em condições normais, não.
O que pode estar havendo é um atraso muito grande de transmissão de
dados do mestre pro escravo. Que tipo de rede os interliga?
   gigabit mesmo barramento


Realmente, não deveria ocorrer isso.


 Isso interfere no cancelamento das consultas longas no escravo, e
consequente pausa na replicação (não aborta a replicação, apenas
pausa) mas isso dura o tempo que uma consulta durar no *escravo*.
Este servidor não está liberado pra ninguém. Está só pra receber a
replicação do mestre.


Então, não é seu caso mesmo, desconsidere este parágrafo.

[]s


__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql

2013-03-27 Por tôpico Flavio Henrique Araque Gurgel 

Em 26-03-2013 12:30, Deliane Andrade escreveu:

Não desligue o escravo quando estiver fazendo esses procedimentos.
VACUUM faz muito log de transação e seu escravo ficou provavelmente
muito atrasado.

Ok. Não desliguei.
Mas o vacuum full ( vacuumdb -v -f -z) do meu master é executado todo
dia à 01:00h da manhã.


Ok. Nada a ver com sua pergunta, mas, por que você faz esse 
procedimento, ainda mais numa versão recente do PostgreSQL?



Hoje fui verificar se alguma alteração feita no meu master, tipo criar
uma tabela de teste, foi replicada para o meu slave.
Nada.


Passe os logs do *escravo* por favor.


Percebi que sempre que ocorre o vacuum no master, parece que a
replicação pára.
Seria possível isso?


Em condições normais, não.
O que pode estar havendo é um atraso muito grande de transmissão de 
dados do mestre pro escravo. Que tipo de rede os interliga?



O meu slave ainda não está disponibilizado para ninguém,além de mim.
Há mais algum desses parâmetro do postgresql.conf que eu deva habilitar
para evitar algo do tipo?

#max_standby_archive_delay = 30s
#max_standby_streaming_delay = 30s
#wal_receiver_status_interval = 10s
#hot_standby_feedback = off


Isso interfere no cancelamento das consultas longas no escravo, e 
consequente pausa na replicação (não aborta a replicação, apenas 
pausa) mas isso dura o tempo que uma consulta durar no *escravo*.


[]s

__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql

2013-03-26 Por tôpico Deliane Andrade 
Boa tarde.

 Em 25 de março de 2013 17:29, Flavio Henrique Araque Gurgel 
fla...@4linux.com.br escreveu:
Não desligue o escravo quando estiver fazendo esses procedimentos.
VACUUM faz muito log de transação e seu escravo ficou provavelmente muito
atrasado.

Ok. Não desliguei.
Mas o vacuum full ( vacuumdb -v -f -z) do meu master é executado todo dia à
01:00h da manhã.
Hoje fui verificar se alguma alteração feita no meu master, tipo criar uma
tabela de teste, foi replicada para o meu slave.
Nada.
Percebi que sempre que ocorre o vacuum no master, parece que a replicação
pára.
Seria possível isso?
O meu slave ainda não está disponibilizado para ninguém,além de mim.
Há mais algum desses parâmetro do postgresql.conf que eu deva habilitar
para evitar algo do tipo?

#max_standby_archive_delay = 30s

#max_standby_streaming_delay = 30s
#wal_receiver_status_interval = 10s
#hot_standby_feedback = off

Att,
 Deliane Andrade
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql

2013-03-25 Por tôpico Matheus de Oliveira 
2013/3/22 Deliane Andrade deliane.andr...@gmail.com

 Oi Matheus.
 Boa tarde.
 O ip do servidor master estava errado.




 standby_mode = 'on'
 primary_conninfo = 'host=192.168.200.46 port=5432 user=replicacao
 password =replicacao'


 Aqui você está realizando a conexão no servidor 192.168.200.46, que
 parece ser o seu slave não o master. Correto?
 CORRETO.

 trigger_file = '/local/script/failover.trg'
 
 CORRIGIDO.
 Agora ta tudo certo.

 Obrigada pelo toque. :)


Tranquilo...


 Tenho uma dúvida ainda.
 O meu script de vacuum/backup é disparado pelo crontab às 00:00h todo dia.
 Ele tira as permissões do banco antes de fazer o vaccum e backup e só
 retorna as mesmas após a conclusão dos mesmos.

 Está aí o trecho do script :

 # Declaracao de variaveis
 BASE2=base_oficial
 HBA=/dbprod/data/
 MSG1=- Acesso ao banco retirado com sucesso...
 MSG2=- Retornado acessos ao banco...

 # Retirando acessos ao banco
 mv $HBApg_hba.conf $HBApg_hba.conf_ori
 mv $HBApg_hba.conf_bck $HBApg_hba.conf
 chown postgres.postgres $HBApg_hba.conf  /etc/init.d/postgresql reload
 echo $MSG1
 ..
 ..
 # Voltando acesso ao banco
 mv $HBApg_hba.conf $HBApg_hba.conf_bck
 mv $HBApg_hba.conf_ori $HBApg_hba.conf
 chown postgres.postgres $HBApg_hba.conf  /etc/init.d/postgresql reload
 echo $MSG2

 Ao retirar estas permissões quando retornar a replicação continuará
 normalmente ou afetará o meu slave?



Quando você altera o pg_hba.conf e executa um reload, as alterações vão
valer apenas para novas conexões, ou seja, aquelas que já haviam sido
estabelecidas não serão afetadas. E, como acredito que o slave não perde a
conexão, o mesmo não será afetado por esta operação (o que não seria
verdade se você reiniciasse o PostgreSQL, seja no slave ou no master).

Entretanto... Eu não vejo nenhum motivo para você realizar uma operação
dessas, pelo contrário, vejos motivos para não fazer isso. Imagine que por
algum motivo seu script tem a execução interrompida antes de voltar o
pg_hba.conf original; nesse caso ninguém mais conecta no banco até que
alguém arrume isso manualmente? E mais, não há necessidade de parar ou
bloquear conexões para executar nem backup e nem vacuum, ambos irão
bloquear operações dos usuários se e quando necessário.

Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql

2013-03-25 Por tôpico Deliane Andrade 
 
 Ao retirar estas permissões quando retornar a replicação continuará
 normalmente ou afetará o meu slave?



 Quando você altera o pg_hba.conf e executa um reload, as alterações
 vão valer apenas para novas conexões, ou seja, aquelas que já haviam sido
 estabelecidas não serão afetadas. E, como acredito que o slave não perde a
 conexão, o mesmo não será afetado por esta operação (o que não seria
 verdade se você reiniciasse o PostgreSQL, seja no slave ou no master).

 Entretanto... Eu não vejo nenhum motivo para você realizar uma operação
 dessas, pelo contrário, vejos motivos para não fazer isso. Imagine que por
 algum motivo seu script tem a execução interrompida antes de voltar o
 pg_hba.conf original; nesse caso ninguém mais conecta no banco até que
 alguém arrume isso manualmente? E mais, não há necessidade de parar ou
 bloquear conexões para executar nem backup e nem vacuum, ambos irão
 bloquear operações dos usuários se e quando necessário.

 Atenciosamente,
 --
 Matheus de Oliveira
 Analista de Banco de Dados
 Dextra Sistemas - MPS.Br nível F!
 www.dextra.com.br/postgres


Olá,boa tarde.
Exclui esse trecho do meu script que retira as permissões.
Mas notei que após rodar o VACUUM FULL no MASTER o slave não iniciou mais.
Ele reclama de algum arquivo no pg_clog.
Será que o vacuum full afetou o  meu slave?
Att,
 Deliane Andrade



 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql

2013-03-25 Por tôpico Deliane Andrade 
No e-mail anterior não postei a mensagem do log:

%%2013-03-25 17:03:44.321 BRTLOG:  sistema de banco de dados foi
desligado durante recuperação em 2013-03-24 10:06:26 BRT
%%2013-03-25 17:03:44.321 BRTLOG:  entrando no modo em espera
%%2013-03-25 17:03:44.329 BRTLOG:  redo inicia em E3/F20
[desconhecido]%[desconhecido]%2013-03-25 17:03:50.623 BRTLOG:  conexão
recebida: host=[local]
postgres%postgres%2013-03-25 17:03:50.623 BRTFATAL:  o sistema de banco
de dados está iniciando

Att,
 Deliane Andrade


Em 25 de março de 2013 15:53, Deliane Andrade
deliane.andr...@gmail.comescreveu:


 
 Ao retirar estas permissões quando retornar a replicação continuará
 normalmente ou afetará o meu slave?



 Quando você altera o pg_hba.conf e executa um reload, as alterações
 vão valer apenas para novas conexões, ou seja, aquelas que já haviam sido
 estabelecidas não serão afetadas. E, como acredito que o slave não perde a
 conexão, o mesmo não será afetado por esta operação (o que não seria
 verdade se você reiniciasse o PostgreSQL, seja no slave ou no master).

 Entretanto... Eu não vejo nenhum motivo para você realizar uma operação
 dessas, pelo contrário, vejos motivos para não fazer isso. Imagine que por
 algum motivo seu script tem a execução interrompida antes de voltar o
 pg_hba.conf original; nesse caso ninguém mais conecta no banco até que
 alguém arrume isso manualmente? E mais, não há necessidade de parar ou
 bloquear conexões para executar nem backup e nem vacuum, ambos irão
 bloquear operações dos usuários se e quando necessário.

 Atenciosamente,
 --
 Matheus de Oliveira
 Analista de Banco de Dados
 Dextra Sistemas - MPS.Br nível F!
 www.dextra.com.br/postgres

 
 Olá,boa tarde.
 Exclui esse trecho do meu script que retira as permissões.
 Mas notei que após rodar o VACUUM FULL no MASTER o slave não iniciou mais.
 Ele reclama de algum arquivo no pg_clog.
 Será que o vacuum full afetou o  meu slave?
 Att,
  Deliane Andrade



 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral



___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql

2013-03-25 Por tôpico Flavio Henrique Araque Gurgel 


Em 25-03-2013 17:07, Deliane Andrade escreveu:

No e-mail anterior não postei a mensagem do log:

%%2013-03-25 17:03:44.321 BRTLOG:  sistema de banco de dados foi
desligado durante recuperação em 2013-03-24 10:06:26 BRT
%%2013-03-25 17:03:44.321 BRTLOG:  entrando no modo em espera
%%2013-03-25 17:03:44.329 BRTLOG:  redo inicia em E3/F20
[desconhecido]%[desconhecido]%2013-03-25 17:03:50.623 BRTLOG:
conexão recebida: host=[local]
postgres%postgres%2013-03-25 17:03:50.623 BRTFATAL:  o sistema de
banco de dados está iniciando


Não desligue o escravo quando estiver fazendo esses procedimentos.
VACUUM faz muito log de transação e seu escravo ficou provavelmente 
muito atrasado.


[]s


__
Flavio Henrique A. Gurgel
Líder de Projetos Especiais
Consultoria, Projetos  Treinamentos 4LINUX
Tel1: +55-11.2125-4747 ou 2125-4748
www.4linux.com.br
email: fla...@4linux.com.br
__
FREE SOFTWARE SOLUTIONS
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Replicação nativa do postgresql

2013-03-22 Por tôpico Deliane Andrade 
Boa tarde a todos.
Estou tentando utilizar a replicação nativa do postgresql 9.2,mas não
identifiquei qual o problema, pois a base slave não sobe após o processo.
Ressalto que fiz os mesmos passos em outros dois servidores( um simulando o
meu produção/master e o outro simulando o meu slave) e funcionou.
Seguem os passos seguidos:

NO MASTER:

editei o postgresql.conf

listen_addresses = '*'
wal_level = hot_standby
max_wal_senders = 1
wal_keep_segments = 32

Restartei o postgresql.

criei  o seguinte usuario:

postgres=#
postgres=# CREATE ROLE replicacao LOGIN REPLICATION PASSWORD 'replicacao';
CREATE ROLE


editei o pg_hba.conf

host replication replicacao 192.168.200.46/32  md5

NO SLAVE:

editei o postgresql.conf
hot_standby = on

criei o arquivo recovery.conf no mesmo diretório do postgresql.conf com o
seguinte conteúdo:

standby_mode = 'on'
primary_conninfo = 'host=192.168.200.46 port=5432 user=replicacao password
=replicacao'
trigger_file = '/local/script/failover.trg'

Parei os dois postmasters.

Reiniciei o MASTER

(Tenho que fazer a cópia com o MASTER rodando)


postgres@dbteste:~$ psql
psql (9.2.2)
Digite help para ajuda.
postgres=# select pg_start_backup('replicacao', true);
pg_start_backup
-
0/5044CB4
(1 row)
postgres=# \q

postgres@dbteste:~$ rsync -a -v -e ssh /dbprod/data/
192.168.200.46:/dbprod/data/
--exclude postmaster.pid

RESULTADO DO rsync :

sent 26776580460 bytes  received 236148 bytes  11569158.18 bytes/sec
total size is 26776480623  speedup is 1.00


NO SLAVE:

editei o  postgresql.conf colocar  hot_standby = on

postgres@dbteste:~$ psql
psql (9.2.2)
Digite help para ajuda.


NO MASTER :

postgres=# select pg_stop_backup();
NOTA:  arquivamento do WAL não está habilitado; você deve garantir que
todos os segmentos do WAL necessários foram copiados por outros meios para
completar a cópia de segurança
 pg_stop_backup

 B/A3002460
(1 registro)


Fui iniciar o postmaster slave :

/etc/init.d/postgres start
Starting PostgreSQL: ok

/etc/init.d/postgres status
pg_ctl: servidor está executando (PID: 27913)
/usr/local/pgsql/bin/postgres -D /dbprod/data

mas quando executo comando exibe a mensagem abaixo:

postgres@marco:~$ psql
psql: FATAL:  o sistema de banco de dados está iniciando

o log me mostra o seguinte :


[desconhecido]%[desconhecido]%2013-03-22 12:05:13.147 BRTLOG:  conexão
recebida: host=192.168.200.46 porta=35976
replicacao%[desconhecido]%2013-03-22 12:05:13.148 BRTFATAL:  o sistema de
banco de dados está iniciando
%%2013-03-22 12:05:13.148 BRTFATAL:  não pôde conectar ao servidor
principal: FATAL:  o sistema de banco de dados está iniciando

[desconhecido]%[desconhecido]%2013-03-22 12:05:18.152 BRTLOG:  conexão
recebida: host=192.168.200.46 porta=35977
replicacao%[desconhecido]%2013-03-22 12:05:18.153 BRTFATAL:  o sistema de
banco de dados está iniciando
%%2013-03-22 12:05:18.153 BRTFATAL:  não pôde conectar ao servidor
principal: FATAL:  o sistema de banco de dados está iniciando

[desconhecido]%[desconhecido]%2013-03-22 12:05:23.157 BRTLOG:  conexão
recebida: host=192.168.200.46 porta=35978
replicacao%[desconhecido]%2013-03-22 12:05:23.158 BRTFATAL:  o sistema de
banco de dados está iniciando
%%2013-03-22 12:05:23.158 BRTFATAL:  não pôde conectar ao servidor
principal: FATAL:  o sistema de banco de dados está iniciando

Alguém teria uma sugestão de qual seria o problema?
Att,
Deliane Andrade
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql

2013-03-22 Por tôpico Matheus de Oliveira 
2013/3/22 Deliane Andrade deliane.andr...@gmail.com


 Boa tarde a todos.


Boa tarde.


 Estou tentando utilizar a replicação nativa do postgresql 9.2,mas não
 identifiquei qual o problema, pois a base slave não sobe após o processo.
 Ressalto que fiz os mesmos passos em outros dois servidores( um simulando
 o meu produção/master e o outro simulando o meu slave) e funcionou.
 Seguem os passos seguidos:

 NO MASTER:

 (...)


Ok.



 editei o pg_hba.conf

 host replication replicacao 192.168.200.46/32  md5

 (...)


Ok.


 standby_mode = 'on'
 primary_conninfo = 'host=192.168.200.46 port=5432 user=replicacao password
 =replicacao'


Aqui você está realizando a conexão no servidor 192.168.200.46, que parece
ser o seu slave não o master. Correto?



 trigger_file = '/local/script/failover.trg'



(...)



postgres@marco:~$ psql
 psql: FATAL:  o sistema de banco de dados está iniciando

 o log me mostra o seguinte :


 [desconhecido]%[desconhecido]%2013-03-22 12:05:13.147 BRTLOG:  conexão
 recebida: host=192.168.200.46 porta=35976
 replicacao%[desconhecido]%2013-03-22 12:05:13.148 BRTFATAL:  o sistema
 de banco de dados está iniciando
 %%2013-03-22 12:05:13.148 BRTFATAL:  não pôde conectar ao servidor
 principal: FATAL:  o sistema de banco de dados está iniciando

 [desconhecido]%[desconhecido]%2013-03-22 12:05:18.152 BRTLOG:  conexão
 recebida: host=192.168.200.46 porta=35977
 replicacao%[desconhecido]%2013-03-22 12:05:18.153 BRTFATAL:  o sistema
 de banco de dados está iniciando
 %%2013-03-22 12:05:18.153 BRTFATAL:  não pôde conectar ao servidor
 principal: FATAL:  o sistema de banco de dados está iniciando

 [desconhecido]%[desconhecido]%2013-03-22 12:05:23.157 BRTLOG:  conexão
 recebida: host=192.168.200.46 porta=35978
 replicacao%[desconhecido]%2013-03-22 12:05:23.158 BRTFATAL:  o sistema
 de banco de dados está iniciando
 %%2013-03-22 12:05:23.158 BRTFATAL:  não pôde conectar ao servidor
 principal: FATAL:  o sistema de banco de dados está iniciando

 Alguém teria uma sugestão de qual seria o problema?


Se o que eu passei acima não for o problema, poste as mensagens do log do
início da conexão (após o start).


Atenciosamente,
-- 
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Replicação nativa do postgresql

2013-03-22 Por tôpico Deliane Andrade 
Oi Matheus.
Boa tarde.
O ip do servidor master estava errado.



 standby_mode = 'on'
 primary_conninfo = 'host=192.168.200.46 port=5432 user=replicacao password
 =replicacao'


Aqui você está realizando a conexão no servidor 192.168.200.46, que parece
ser o seu slave não o master. Correto?
CORRETO.

trigger_file = '/local/script/failover.trg'

CORRIGIDO.
Agora ta tudo certo.

Obrigada pelo toque. :)

Tenho uma dúvida ainda.
O meu script de vacuum/backup é disparado pelo crontab às 00:00h todo dia.
Ele tira as permissões do banco antes de fazer o vaccum e backup e só
retorna as mesmas após a conclusão dos mesmos.

Está aí o trecho do script :

# Declaracao de variaveis
BASE2=base_oficial
HBA=/dbprod/data/
MSG1=- Acesso ao banco retirado com sucesso...
MSG2=- Retornado acessos ao banco...

# Retirando acessos ao banco
mv $HBApg_hba.conf $HBApg_hba.conf_ori
mv $HBApg_hba.conf_bck $HBApg_hba.conf
chown postgres.postgres $HBApg_hba.conf  /etc/init.d/postgresql reload
echo $MSG1
..
..
# Voltando acesso ao banco
mv $HBApg_hba.conf $HBApg_hba.conf_bck
mv $HBApg_hba.conf_ori $HBApg_hba.conf
chown postgres.postgres $HBApg_hba.conf  /etc/init.d/postgresql reload
echo $MSG2

Ao retirar estas permissões quando retornar a replicação continuará
normalmente ou afetará o meu slave?
Att,
 Deliane Andrade.





 ___
 pgbr-geral mailing list
 pgbr-geral@listas.postgresql.org.br
 https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral