Re: [pgbr-geral] Upgrade da versão 8.4.4 p/ vers ão 9.0.1

2010-11-12 Por tôpico André Ormenese (particular) 
Em 12/11/2010 11:41, Euler Taveira de Oliveira escreveu:
> André Ormenese (particular) escreveu:
>> relarr_lookup_rel (ctx=0x7fffdb40, rel_arr=0x448,
>>   nspname=0x800b45000 "pg_catalog", relname=0x800b45040
>> "pg_largeobject",
>>   whichCluster=CLUSTER_OLD) at info.c:428
>> 428 for (relnum = 0; relnum<  rel_arr->nrels; relnum++)
>> (gdb) p rel_arr->nrels
>> Error accessing memory address 0x450: Bad address.
>> (gdb) p rel_arr->rels->reloid
>> Error accessing memory address 0x448: Bad address.
>>
> Este erro é muito estranho. relnum é realmente zero?
>
> (gdb) p relnum
>
> Veja se o patch [1] resolve o seu problema.
>
> Esta base está corrompida? Você consegue fazer uma consulta em pg_largeobject
> neste banco de dados?
>
>
> [1]
> http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=71baff1786e0c50b514745c64c4b0947b64bf9d0;hp=9f376e146b2f1fe1bc4d07380f2a047d5c375581
>
>
Durante esta semana constatei que uma tabela esta (acho) corrompida. Eu 
não consigo fazer um dump dos dados desta unica tabela.

Veja o log do banco :

LOG:  server process (PID 63471) was terminated by signal 11: 
Segmentation fault
LOG:  terminating any other active server processes
LOG:  archiver process (PID 63356) exited with exit code 1
LOG:  all server processes terminated; reinitializing
LOG:  database system was interrupted; last known up at 2010-11-12 
15:52:09 BRST
LOG:  database system was not properly shut down; automatic recovery in 
progress
LOG:  redo starts at 8/CB68
LOG:  invalid magic number  in log file 8, segment 203, offset 1835008
LOG:  redo done at 8/CB1BF650
LOG:  database system is ready to accept connections
LOG:  autovacuum launcher started

E esta é a mensagem do pg_dump :

pg_dump: Dumping the contents of table "cad_sor" failed: PQgetCopyData() 
failed.
pg_dump: Error message from server: server closed the connection 
unexpectedly
 This probably means the server terminated abnormally
 before or while processing the request.

Se eu der um select * from cad_sor; nesta tabela também dá erro.

Como estou na base de teste, acabei apagando o conteúdo da tabela p/ 
fazer testes com o pg_upgrade.

Fiz uma consulta em pg_largeobject, sem dar erro, e não retornou nenhuma 
linha.

Deletei o conteúdo e passei vaccum analyze no banco.

Fiz a alteração no /PATH_BANCO/contrib/pg_upgrade/controldata.c

Recompilei e instalei o pg_upgrade e pg_upgrade_support

Rodei o pg_upgrade através do gdb, mas continua dando o mesmo erro :

Restoring user relation files

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x800b020b0 (LWP 100137)]
relarr_lookup_rel (ctx=0x7fffdb40, rel_arr=0x448,
 nspname=0x800b45000 "pg_catalog", relname=0x800b45040 
"pg_largeobject",
 whichCluster=CLUSTER_OLD) at info.c:428
428 for (relnum = 0; relnum < rel_arr->nrels; relnum++)
(gdb) p relnum
Variable "relnum" is not available.



Como disse no email anterior, achei muito estranho a qtd de parâmetros 
na função putenv2. Até tentei pegar a função toda e recompilar, mas aí 
não compila dá um monte de erros. O que fiz foi alterar somente a linha 
mostrada pelo commitdiff.





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

Re: [pgbr-geral] Upgrade da versão 8.4.4 p/ vers ão 9.0.1

2010-11-12 Por tôpico André Ormenese (particular) 

Em 12/11/2010 11:41, Euler Taveira de Oliveira escreveu:

André Ormenese (particular) escreveu:

relarr_lookup_rel (ctx=0x7fffdb40, rel_arr=0x448,
  nspname=0x800b45000 "pg_catalog", relname=0x800b45040
"pg_largeobject",
  whichCluster=CLUSTER_OLD) at info.c:428
428 for (relnum = 0; relnum<  rel_arr->nrels; relnum++)
(gdb) p rel_arr->nrels
Error accessing memory address 0x450: Bad address.
(gdb) p rel_arr->rels->reloid
Error accessing memory address 0x448: Bad address.


Este erro é muito estranho. relnum é realmente zero?

(gdb) p relnum

Veja se o patch [1] resolve o seu problema.

Esta base está corrompida? Você consegue fazer uma consulta em pg_largeobject
neste banco de dados?


[1]
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=71baff1786e0c50b514745c64c4b0947b64bf9d0;hp=9f376e146b2f1fe1bc4d07380f2a047d5c375581


Estou fazendo alguns testes ainda, e uma doc sobre o problema, mas com 
relação ao patch achei muito estranho uma situação.


No arquivo controldata.c da minha máquina a função putenv2 recebe 3 
parametros ao invés de dois como diz a própria documentação, veja :


/*
 *  putenv2()
 *
 *  This is like putenv(), *but takes two arguments*.
 *  It also does unsetenv() if val is NULL.
 */
static void
putenv2(*migratorContext *ctx, const char *var, const char *val*)
{
if (val)
{
#ifndef WIN32
char   *envstr = (char *) pg_malloc(ctx, strlen(var) +

strlen(val) + 1);

sprintf(envstr, "%s=%s", var, val);
putenv(envstr);
/*
 *  Do not free envstr because it becomes part of 
the environment
 *  on some operating systems.  See 
port/unsetenv.c::unsetenv.

 */
#else
SetEnvironmentVariableA(var, val);
#endif
}
else
{
#ifndef WIN32
unsetenv(var);
#else
SetEnvironmentVariableA(var, "");
#endif

Não sei se esta função é usada na execução do pg_upgrade aqui p/ o meu 
banco, mas é bem estranho.

Seria melhor baixar os fontes novamente e reinstalar a versão 9.01 ??

Depois passo as outras informações que vc pediu !!!


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

Re: [pgbr-geral] Upgrade da versão 8.4.4 p/ vers ão 9.0.1

2010-11-10 Por tôpico André Ormenese (particular) 
Em 10/11/2010 12:54, Euler Taveira de Oliveira escreveu:
> André Ormenese (particular) escreveu:
>> relarr_lookup_rel (ctx=0x7fffdb40, rel_arr=0x448,
>>   nspname=0x800b45000 "pg_catalog", relname=0x800b45040
>> "pg_largeobject",
>>   whichCluster=CLUSTER_OLD) at info.c:428
>> 428 for (relnum = 0; relnum<  rel_arr->nrels; relnum++)
> Mostre a saída de:
>
> (gdb) p rel_arr->nrels
>
> (gdb) p rel_arr->rels->reloid
>
>
> Você possui _large objects_ (LOB) neste banco de dados?
>
>
Não possuo LOB no banco de dados !!!


relarr_lookup_rel (ctx=0x7fffdb40, rel_arr=0x448,
 nspname=0x800b45000 "pg_catalog", relname=0x800b45040 
"pg_largeobject",
 whichCluster=CLUSTER_OLD) at info.c:428
428 for (relnum = 0; relnum < rel_arr->nrels; relnum++)
(gdb) p rel_arr->nrels
Error accessing memory address 0x450: Bad address.
(gdb) p rel_arr->rels->reloid
Error accessing memory address 0x448: Bad address.


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

Re: [pgbr-geral] Upgrade da versão 8.4.4 p/ vers ão 9.0.1

2010-11-10 Por tôpico André Ormenese (particular) 
Em 10/11/2010 11:58, Euler Taveira de Oliveira escreveu:
> André Ormenese (particular) escreveu:
>> (gdb) bt
>> #0  0x00405f8d in relarr_lookup_rel ()
>> #1  0x004060ef in gen_db_file_maps ()
>> #2  0x0040779a in transfer_all_new_dbs ()
>> #3  0x00407198 in main ()
>> (gdb)
>>
> Hmmm. Seria possível repetir o processo adicionando os símbolos de depuração?
> Basta recompilar o pg_upgrade com a opção -g (edite o Makefile e adicione a
> opção -g a linha PG_CPPFLAGS). Assim podemos descobrir qual das chamadas do
> relarr_lookup_rel() está causando o SIGSEGV.
>
>
Euler, segue resultado do debug :


%gdb ./pg_upgrade
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...
(gdb) r
Starting program: /dados/bancos/pghemo9/bin/pg_upgrade
[New LWP 100153]
[New Thread 0x800b020b0 (LWP 100153)]
Performing Consistency Checks
-
Checking old data directory (/dados/bancos/pg_hemo/data)ok
Checking old bin directory (/dados/bancos/pg_hemo/bin)  ok
Checking new data directory (/dados/bancos/pghemo9/data)ok
Checking new bin directory (/dados/bancos/pghemo9/bin)  ok
Checking for reg* system oid user data typesok
Checking for /contrib/isn with bigint-passing mismatch  ok
Checking for large objects  ok
Creating catalog dump   ok
Checking for presence of required libraries ok

| If pg_upgrade fails after this point, you must
| re-initdb the new cluster before continuing.
| You will also need to remove the ".old" suffix
| from /dados/bancos/pg_hemo/data/global/pg_control.old.

Performing Migration

Adding ".old" suffix to old global/pg_control   ok
Analyzing all rows in the new cluster   ok
Freezing all rows on the new clusterok
Deleting new commit clogs   ok
Copying old commit clogs to new server  ok
Setting next transaction id for new cluster ok
Resetting WAL archives  ok
Setting frozenxid counters in new cluster   ok
Creating databases in the new cluster   ok
Adding support functions to new cluster ok
Restoring database schema to new clusterok
Removing support functions from new cluster ok
Restoring user relation files

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x800b020b0 (LWP 100153)]
relarr_lookup_rel (ctx=0x7fffdb40, rel_arr=0x448,
 nspname=0x800b45000 "pg_catalog", relname=0x800b45040 
"pg_largeobject",
 whichCluster=CLUSTER_OLD) at info.c:428
428 for (relnum = 0; relnum < rel_arr->nrels; relnum++)
(gdb) bt
#0  relarr_lookup_rel (ctx=0x7fffdb40, rel_arr=0x448,
 nspname=0x800b45000 "pg_catalog", relname=0x800b45040 
"pg_largeobject",
 whichCluster=CLUSTER_OLD) at info.c:428
#1  0x004060ef in gen_db_file_maps (ctx=0x7fffdb40, old_db=0x0,
 new_db=0x800b4e000, nmaps=0x7fffdabc,
 old_pgdata=0x800b1a040 "/dados/bancos/pg_hemo/data",
 new_pgdata=0x800b1a060 "/dados/bancos/pghemo9/data") at info.c:69
#2  0x0040779a in transfer_all_new_dbs (ctx=0x7fffdb40,
 olddb_arr=0x7fffdb98, newdb_arr=0x7fffdc38,
 old_pgdata=0x800b1a040 "/dados/bancos/pg_hemo/data",
 new_pgdata=0x800b1a060 "/dados/bancos/pghemo9/data") at 
relfilenode.c:50
#3  0x00407198 in main (argc=Variable "argc" is not available.
) at pg_upgrade.c:74
(gdb)


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

Re: [pgbr-geral] Upgrade da versão 8.4.4 p/ vers ão 9.0.1

2010-11-09 Por tôpico André Ormenese (particular) 
Em 05/11/2010 18:17, Euler Taveira de Oliveira escreveu:
> André Ormenese (particular) escreveu:
>> Restoring user relation files
>> Segmentation fault (core dumped)
>>
> Podes realizar os seguintes passos ...
>
> $ gdb /path/to/pg_upgrade
> .
> .
> .
> (gdb) r
> .
> .
> .
> (gdb) bt
> .
> .
> .
> (gdb) quit
>
> e enviar a saída?
>
>
Euler e demais,

refiz todo o processo em outra máquina e agora o retorno do gdb é este :

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging 
symbols found)...
(gdb) r
Starting program: /dados/bancos/pghemo9/bin/pg_upgrade
(no debugging symbols found)...(no debugging symbols found)...(no 
debugging symbols found)...[New LWP 100388]
(no debugging symbols found)...[New Thread 0x800b020b0 (LWP 100388)]
Performing Consistency Checks
-
Checking old data directory (/dados/bancos/pg_hemo/data)ok
Checking old bin directory (/dados/bancos/pg_hemo/bin)  ok
Checking new data directory (/dados/bancos/pghemo9/data)ok
Checking new bin directory (/dados/bancos/pghemo9/bin)  ok
Checking for reg* system oid user data typesok
Checking for /contrib/isn with bigint-passing mismatch  ok
Checking for large objects  ok
Creating catalog dump   ok
Checking for presence of required libraries ok

| If pg_upgrade fails after this point, you must
| re-initdb the new cluster before continuing.
| You will also need to remove the ".old" suffix
| from /dados/bancos/pg_hemo/data/global/pg_control.old.

Performing Migration

Adding ".old" suffix to old global/pg_control   ok
Analyzing all rows in the new cluster   ok
Freezing all rows on the new clusterok
Deleting new commit clogs   ok
Copying old commit clogs to new server  ok
Setting next transaction id for new cluster ok
Resetting WAL archives  ok
Setting frozenxid counters in new cluster   ok
Creating databases in the new cluster   ok
Adding support functions to new cluster ok
Restoring database schema to new clusterok
Removing support functions from new cluster ok
Restoring user relation files

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x800b020b0 (LWP 100388)]
0x00405f8d in relarr_lookup_rel ()
(gdb) bt
#0  0x00405f8d in relarr_lookup_rel ()
#1  0x004060ef in gen_db_file_maps ()
#2  0x0040779a in transfer_all_new_dbs ()
#3  0x00407198 in main ()
(gdb)



Mais uma vez obrigado pela força !!!
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Upgrade da versão 8.4.4 p/ vers ão 9.0.1

2010-11-08 Por tôpico André Ormenese (particular) 
Em 05/11/2010 18:17, Euler Taveira de Oliveira escreveu:
> André Ormenese (particular) escreveu:
>> Restoring user relation files
>> Segmentation fault (core dumped)
>>
> Podes realizar os seguintes passos ...
>
> $ gdb /path/to/pg_upgrade
> .
> .
> .
> (gdb) r
> .
> .
> .
> (gdb) bt
> .
> .
> .
> (gdb) quit
>
> e enviar a saída?
>
>
Agora sim !

Executei o gdb utilizando os parâmetros do pg_upgrade definidos através 
do setenv !!!


%gdb /dados/bancos/pg_hemo/bin/pg_upgrade
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols 
found)...
(gdb) r
Starting program: /dados/bancos/pg_hemo/bin/pg_upgrade
(no debugging symbols found)...(no debugging symbols found)...(no 
debugging symbols found)...warning: Unable to get location for thread 
creation breakpoint: generic error
[New LWP 100179]
(no debugging symbols found)...[New Thread 0x8065000 (LWP 100179)]
Performing Consistency Checks
-
Checking old data directory (/dados/bancos/pg_hemo.old/data)ok
Checking old bin directory (/dados/bancos/pg_hemo.old/bin)  ok
Checking new data directory (/dados/bancos/pg_hemo/data)ok
Checking new bin directory (/dados/bancos/pg_hemo/bin)  ok


pg_upgrade_support.so must be created and installed in 
/pg_upgrade_support.so

Program exited with code 01.
(gdb)


Confirmo que fiz a instalação do pg_upgrade_support através do contrib. 
Vou tentar instalar novamente ...
É isso que devo fazer, ou preciso executa algum outro processo ??

Obrigado




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

Re: [pgbr-geral] Upgrade da versão 8.4.4 p/ vers ão 9.0.1

2010-11-08 Por tôpico André Ormenese (particular) 
Em 05/11/2010 18:17, Euler Taveira de Oliveira escreveu:
> André Ormenese (particular) escreveu:
>> Restoring user relation files
>> Segmentation fault (core dumped)
>>
> Podes realizar os seguintes passos ...
>
> $ gdb /path/to/pg_upgrade
> .
> .
> .
> (gdb) r
> .
> .
> .
> (gdb) bt
> .
> .
> .
> (gdb) quit
>
> e enviar a saída?
>
>
Euler,
executei o comando que vc sugeriu. Segue resultado :

**

%gdb /dados/bancos/pg_hemo/bin/pg_upgrade
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols 
found)...
(gdb) r
Starting program: /dados/bancos/pg_hemo/bin/pg_upgrade
(no debugging symbols found)...(no debugging symbols found)...(no 
debugging symbols found)...warning: Unable to get location for thread 
creation breakpoint: generic error
[New LWP 100196]
(no debugging symbols found)...[New Thread 0x8065000 (LWP 100196)]

You must identify the directory where the old cluster data resides
Please use the -d command-line option or the OLDDATADIR environment variable

Program exited with code 01.

***

Mediante este resultado, tentei executar de outra forma, passando os 
parâmetros do pg_upgrade e também executou corretamente o gdb :

%gdb /dados/bancos/pg_hemo/bin/pg_upgrade -d 
/dados/bancos/pg_hemo.old/data -D /dados/bancos/pg_hemo/data -b 
/dados/bancos/pg_hemo.old/bin -B /dados/bancos/pg_hemo/bin
gdb: unrecognized option `-D'
Use `gdb --help' for a complete list of options.





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

[pgbr-geral] Upgrade da versão 8.4.4 p/ vers ão 9.0.1

2010-11-05 Por tôpico André Ormenese (particular) 
Boa tarde a todos 
Estou tentando fazer um upgrade da versão 8.4.4 p/ a versão 9.0.1 
utlizando o pg_upgrade.

Estou rodando em freebsd.

O pg_upgrade --check passa sem problemas !!! Mas qdo vou fazer a 
migração definitiva acontece o seguinte erro :

Performing Migration

Adding ".old" suffix to old global/pg_control   ok
Analyzing all rows in the new cluster   ok
Freezing all rows on the new clusterok
Deleting new commit clogs   ok
Copying old commit clogs to new server  ok
Setting next transaction id for new cluster ok
Resetting WAL archives  ok
Setting frozenxid counters in new cluster   ok
Creating databases in the new cluster   ok
Adding support functions to new cluster ok
Restoring database schema to new clusterok
Removing support functions from new cluster ok
Restoring user relation files
Segmentation fault (core dumped)


Existe algum log de erro mais detalhado ??
O que pode ser este erro ??
Já migrei uma outra base, que esta na mesma máquina, e não tive 
problemas ...

Obrigado
André


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

Re: [pgbr-geral] Res: Sugestão de servidor.

2010-08-05 Por tôpico André Ormenese (particular) 

 Tem este texto também !!!
Do próprio Telles.

http://www.midstorm.org/~telles/2008/07/25/postgresql-discos-cia/


Em 05/08/2010 16:35, Fabiano Machado Dias escreveu:
Prefiro Intel, já tive problemas com AMD por causa do aquecimento. 
Lembrando que o seu gargalo é disco, gaste o seu dinheiro nele, depois 
memória e depois processador.


Recomendo dar uma olhada na palestra do Telles
http://www.slideshare.net/telles/discos-cia-em-postgresql

Abraço,
Fabiano Machado Dias

Em 5/8/2010 16:25, Alex Barbosa Ferreira escreveu:

Para banco de dados qual processador, um Intel Xeon ou AMD Opteron?
*Alex B. Ferreira*
*/Analista em Segurança da Informação/*



*De:* Nilson Chagas 
*Para:* Comunidade PostgreSQL Brasileira 


*Enviadas:* Quinta-feira, 5 de Agosto de 2010 16:08:09
*Assunto:* Re: [pgbr-geral] Sugestão de servidor.

2010/8/5 Alex Barbosa Ferreira >


Boa tarde!

a empresa em que trabalho decidiu fazer investimento num servidor
para nosso banco de dados, diante desta situação gostaria de
algumas sugestões de configuração.
Atualmente nosso banco de dados está com 50GB e um crescimento
aproximado de 2% por semana.
O servidor atual é biprocessado Xeon com 4GB de memória e dois HD
Sata com placa-mãe Intel sem unidade de backup.



Não sei qual o tamanho do investimento, mas um servidor com 8Gb e HD SAS
Uma mera opinião.

--
[]s
Nilson Chagas - Ubuntu User 25794 (Hospedagem com postgresql a partir 
de R$ 5,00)

---
Visite:
http://www.avozdoevangelho.com.br -> Peça gratuitamente um curso Bíblico

Twitter: avozdoevangelhoTwitter: matrixspnet

http://www.amados.com.br
http://bbnradio.org -> Ouça a rádio e faça gratuitamente um Curso 
Biblico On-Line





___
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


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

Re: [pgbr-geral] PostgreSQL + Heartbeat

2010-07-15 Por tôpico André Ormenese (particular) 


Em 15 de julho de 2010 12:00, "André Ormenese (particular)" 
mailto:ormen...@yahoo.com.br>> escreveu:


Em 14/07/2010 09:32, Luciano Mittmann escreveu:

Opa,

Vc pode usar o Monit http://mmonit.com/monit/

Att,

Em 14 de julho de 2010 09:01, "André Ormenese (particular)"
mailto:ormen...@yahoo.com.br>> escreveu:

Em 13/07/2010 16:56, JotaComm escreveu:

Olá,

    Em 13 de julho de 2010 16:32, "André Ormenese (particular)"
mailto:ormen...@yahoo.com.br>> escreveu:

 Boa tarde,
pessoal montei uma estrutura para alta disponibilidade
do PostgreSQL
utilizando algumas ideias do João Cosme (

http://joaocosme.wordpress.com/2009/10/30/ha-em-postgresql-warm-stand-by-heartbeat-hapm/
).


Uso uma boa referência :)

O heartbeat e a replicação estão funcionando
perfeitamente. Quando tenho
failover de máquina ou rede meu slave assume sem problemas.
A minha dúvida é como monitorar se o banco na máquina
master está
respondendo.


O heartbeat na versão 2.0 senão me falha a memória faz isso.

Vcs conhecem algum software que faça a verificação se o
banco está no
ar, e mande a informação que o banco parou, para o
heartbeat 
Pensei no mon (
https://mon.wiki.kernel.org/index.php/Monitors ), mas
ele não funciona no freebsd ...

Minha versão do banco é 8.4.4.

Obrigado
André


Pois é Jota  o problema é exatamente este, estou com o
heartbeat sem crm, ou seja, versão 1.

Valeu pela dica !!!


Luciano,
pelo o que eu entendi o monit não tem integração com o heartbeat ...

Este tipo de monitoria eu já faço com o nagios.

Obrigado


___



Em 15/07/2010 13:23, Luciano Mittmann escreveu:

André,

Utilizamos o monit para monitorar tanto o heartbeat quanto o postgres, 
quando ele detecta que o serviço deixou de responder(monitoramento de 
porta ou pid) executa um procedimento qualquer definido em seu arquivo 
de configuração, no nosso caso tenta restabelecer o serviço - outras 
ações podem ser tomadas dependendo da necessidade. No seu caso, o 
monit pode ordenar que o heartbeat entre em modo standby.



Luciano.


Então vou dar mais uma olhada !!!

Valeu Luciano




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

Re: [pgbr-geral] PostgreSQL + Heartbeat

2010-07-15 Por tôpico André Ormenese (particular) 

 Em 14/07/2010 09:32, Luciano Mittmann escreveu:

Opa,

Vc pode usar o Monit http://mmonit.com/monit/

Att,

Em 14 de julho de 2010 09:01, "André Ormenese (particular)" 
mailto:ormen...@yahoo.com.br>> escreveu:


Em 13/07/2010 16:56, JotaComm escreveu:

Olá,

Em 13 de julho de 2010 16:32, "André Ormenese (particular)"
mailto:ormen...@yahoo.com.br>> escreveu:

 Boa tarde,
pessoal montei uma estrutura para alta disponibilidade do
PostgreSQL
utilizando algumas ideias do João Cosme (

http://joaocosme.wordpress.com/2009/10/30/ha-em-postgresql-warm-stand-by-heartbeat-hapm/
).


Uso uma boa referência :)

O heartbeat e a replicação estão funcionando perfeitamente.
Quando tenho
failover de máquina ou rede meu slave assume sem problemas.
A minha dúvida é como monitorar se o banco na máquina master está
respondendo.


O heartbeat na versão 2.0 senão me falha a memória faz isso.

Vcs conhecem algum software que faça a verificação se o banco
está no
ar, e mande a informação que o banco parou, para o heartbeat 
Pensei no mon (
https://mon.wiki.kernel.org/index.php/Monitors ), mas
ele não funciona no freebsd ...

Minha versão do banco é 8.4.4.

Obrigado
André


Pois é Jota  o problema é exatamente este, estou com o
heartbeat sem crm, ou seja, versão 1.

Valeu pela dica !!!


Luciano,
pelo o que eu entendi o monit não tem integração com o heartbeat ...

Este tipo de monitoria eu já faço com o nagios.

Obrigado

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

Re: [pgbr-geral] PostgreSQL + Heartbeat

2010-07-14 Por tôpico André Ormenese (particular) 

 Em 13/07/2010 16:56, JotaComm escreveu:

Olá,

Em 13 de julho de 2010 16:32, "André Ormenese (particular)" 
mailto:ormen...@yahoo.com.br>> escreveu:


 Boa tarde,
pessoal montei uma estrutura para alta disponibilidade do PostgreSQL
utilizando algumas ideias do João Cosme (

http://joaocosme.wordpress.com/2009/10/30/ha-em-postgresql-warm-stand-by-heartbeat-hapm/
).


Uso uma boa referência :)

O heartbeat e a replicação estão funcionando perfeitamente. Quando
tenho
failover de máquina ou rede meu slave assume sem problemas.
A minha dúvida é como monitorar se o banco na máquina master está
respondendo.


O heartbeat na versão 2.0 senão me falha a memória faz isso.

Vcs conhecem algum software que faça a verificação se o banco está no
ar, e mande a informação que o banco parou, para o heartbeat 
Pensei no mon ( https://mon.wiki.kernel.org/index.php/Monitors ), mas
ele não funciona no freebsd ...

Minha versão do banco é 8.4.4.

Obrigado
André

Pois é Jota  o problema é exatamente este, estou com o heartbeat sem 
crm, ou seja, versão 1.


Valeu pela dica !!!


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

[pgbr-geral] PostgreSQL + Heartbeat

2010-07-13 Por tôpico André Ormenese (particular) 
  Boa tarde,
pessoal montei uma estrutura para alta disponibilidade do PostgreSQL 
utilizando algumas ideias do João Cosme ( 
http://joaocosme.wordpress.com/2009/10/30/ha-em-postgresql-warm-stand-by-heartbeat-hapm/
  
).
O heartbeat e a replicação estão funcionando perfeitamente. Quando tenho 
failover de máquina ou rede meu slave assume sem problemas.
A minha dúvida é como monitorar se o banco na máquina master está 
respondendo.
Vcs conhecem algum software que faça a verificação se o banco está no 
ar, e mande a informação que o banco parou, para o heartbeat 
Pensei no mon (  https://mon.wiki.kernel.org/index.php/Monitors ), mas 
ele não funciona no freebsd ...

Minha versão do banco é 8.4.4.

Obrigado
André


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