from:"Jean"


Bom dia.

Ontem a noite o banco travou aqui para mim, em um situação estranha.
Tenho o banco instalado em um DELL PE R815 + DELL MD3200 (ligação SAS 
6Gb), rodando Centos 6.4 (Linux olosdb01.olostech.local 
2.6.32-358.14.1.el6.x86_64 #1 SMP Tue Jul 16 23:51:20 UTC 2013 x86_64 
x86_64 x86_64 GNU/Linux) e PostgreSQL (9.2.4 on 
x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 
4.4.7-3), 64-bit).


Já tive um problema sério com essa maquina, que no qual existia um 
problema com o modulo de video, o que fazia todas as CPUs travarem em 
100%, e a unica solução para ela voltar a funcionar era utilizando o 
botão power.
Mas dessa vez aparentemente o servidor estava OK, e somente o postgres 
não respondia, simplismente não o conseguia nem mesmo parar ele.
Só para constar, não apareceu nada em log algum (dmesg, messages, do 
postgres, etc..), nada mesmo.
Como não tinha como matar os processos do banco foi obrigado a dar um 
reboot, que no qual também não foi bem sucedido, que no qual ficou 
travado no ponto de montagem para com a storage (o OS não conseguia 
desmontar a unidade, nem a pau). A solução foi no botão power mesmo.


Gostaria de uma opinião de vocês, já que conhecem melhor o banco.
Eu acredito que seja problema com o servidor e não com o postgres, mas 
em todos os casos não custa perguntar, talvez alguem já tenha passado 
por isso ou seja um bug e tal.


Agradeço desde já.
Jean Pereira.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Travamento


On 08/20/2013 10:26, Guimarães Faria Corcete DUTRA, Leandro wrote:

2013/8/20 Jean Pereira :

Já tive um problema sério com essa maquina, que no qual existia um problema
com o modulo de video, o que fazia todas as CPUs travarem em 100%, e a unica
solução para ela voltar a funcionar era utilizando o botão power.

Problema já resolvido?

Esse já, o suporte contratado demorou mais resolveu.




Mas dessa vez aparentemente o servidor estava OK, e somente o postgres não
respondia, simplismente não o conseguia nem mesmo parar ele.
Só para constar, não apareceu nada em log algum (dmesg, messages, do
postgres, etc..), nada mesmo.

Isso não quer dizer muita coisa…



Como não tinha como matar os processos do banco foi obrigado a dar um
reboot, que no qual também não foi bem sucedido, que no qual ficou travado
no ponto de montagem para com a storage (o OS não conseguia desmontar a
unidade, nem a pau). A solução foi no botão power mesmo.

Problema de E/S, mas sem testes fica difícil falar qualquer coisa.  Ao
reiniciar sem diagnóstico, você perdeu a oportunidade de ver algo sem
esperar pelo próximo problema.

Eu não lembro mais do ferramental todo, mas a primeira coisa que eu
olharia, tentando prevenir algum problema futuro, seriam as
ferramentas de monitoramento Smart (das unidades de armazenamento) e
de diagnóstico do sistemas de arquivos, lembrando também de olhar se
algum dos sistemas de arquivos foi verificado e gerou algum alerta na
reinicialização.
Sim, entendo. Mais 1 minuto para mim parado é muito, sei dos problemas 
que possivelmente podem acontecer quanto a isso. Mas tenho servidor 
reserva, e devo efetuar a troca o mais rápido possível.
Quanto ao tempo de parada... o banco faz parte de um sistema de saúde, 
que no qual tem alguns PA e PS 24h.

Creio que os gurus de plantão acrescentarão detalhes mais úteis que
minhas idéias genéricas…
___
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] Travamento


On 08/20/2013 10:47, Flavio Henrique Araque Gurgel wrote:

Em 20-08-2013 10:03, Jean Pereira escreveu:

Bom dia.

Ontem a noite o banco travou aqui para mim, em um situação estranha.
Tenho o banco instalado em um DELL PE R815 + DELL MD3200 (ligação SAS
6Gb), rodando Centos 6.4 (Linux olosdb01.olostech.local
2.6.32-358.14.1.el6.x86_64 #1 SMP Tue Jul 16 23:51:20 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux) e PostgreSQL (9.2.4 on
x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat
4.4.7-3), 64-bit).


Gostei disso aqui. Bastante informação útil.


Já tive um problema sério com essa maquina, que no qual existia um
problema com o modulo de video, o que fazia todas as CPUs travarem em
100%, e a unica solução para ela voltar a funcionar era utilizando o
botão power.
Mas dessa vez aparentemente o servidor estava OK, e somente o postgres
não respondia, simplismente não o conseguia nem mesmo parar ele.
Só para constar, não apareceu nada em log algum (dmesg, messages, do
postgres, etc..), nada mesmo.
Como não tinha como matar os processos do banco foi obrigado a dar um
reboot, que no qual também não foi bem sucedido, que no qual ficou
travado no ponto de montagem para com a storage (o OS não conseguia
desmontar a unidade, nem a pau). A solução foi no botão power mesmo.


Duas coisas devem ter acontecido:
1) o S.O. não quis desmontar a unidade porque tinha escrita pendente e 
ele estava inacessível;
2) o PostgreSQL não pode ser parado tão facilmente quando tem conexões 
ainda e, talvez, transações em andamento.



Gostaria de uma opinião de vocês, já que conhecem melhor o banco.
Eu acredito que seja problema com o servidor e não com o postgres, mas
em todos os casos não custa perguntar, talvez alguem já tenha passado
por isso ou seja um bug e tal.


Olhe novamente no messages. Procure por indisponibilidade um (ou mais) 
canais de fibra pro Storage. Já aconteceu comigo de fibra cair e 
voltar, mesmo que rapidamente, é o suficiente pra bagunçar as coisas 
de uma forma bem "bacana".


Flavio, pior que não tem nada no messages mesmo, isso que está me 
deixando com a pulga atrás da orelha.
Sobre os cabos, conferi eles no ato, mesmo assim, pela "lógica", tenho 
redundancia de HBA e de Modulo controlador, na teoria 1 cabo não deveria 
dar isso, eu não tenho muita experiencia em hardware, mais acho eu que 
não deveria.
Pergunta: qual sistema de arquivos está usando, e quantos pontos de 
montagem estão disponíveis para o banco?

ext4
Segue mais informações:

   [root@olosdb01 ~]# df -h
   FilesystemSize  Used Avail Use% Mounted on
   /dev/sda1  49G  3.0G   43G   7% /
   tmpfs  32G 0   32G   0% /dev/shm
   /dev/mapper/mpathcp1  1.4T   94G  1.2T   8% /opt/md3200/pgdata
   /dev/mapper/mpathbp1  275G  1.3G  260G   1% /opt/md3200/pgxlog
   /dev/sda5 283G   37G  232G  14% /usr/local/pgsql
   /dev/sda2  97G  279M   91G   1% /var/log
   [root@olosdb01 ~]# multipath -ll
   mpathc (36d4ae52000996c41085151dbf626) dm-1 DELL,MD32xx
   size=1.4T features='3 queue_if_no_path pg_init_retries 50'
   hwhandler='1 rdac' wp=rw
   |-+- policy='round-robin 0' prio=6 status=active
   | |- 1:0:0:1 sdc 8:32  active ready running
   | `- 2:0:1:1 sdi 8:128 active ready running
   `-+- policy='round-robin 0' prio=1 status=enabled
  |- 1:0:1:1 sde 8:64  active ghost running
  `- 2:0:0:1 sdg 8:96  active ghost running
   mpathb (36d4ae5200099721d081d51dbf5b8) dm-0 DELL,MD32xx
   size=279G features='3 queue_if_no_path pg_init_retries 50'
   hwhandler='1 rdac' wp=rw
   |-+- policy='round-robin 0' prio=6 status=active
   | |- 1:0:1:0 sdd 8:48  active ready running
   | `- 2:0:0:0 sdf 8:80  active ready running
   `-+- policy='round-robin 0' prio=1 status=enabled
  |- 1:0:0:0 sdb 8:16  active ghost running
  `- 2:0:1:0 sdh 8:112 active ghost running




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

Re: [pgbr-geral] Travamento


On 08/20/2013 16:24, Flavio Henrique Araque Gurgel wrote:

Em 20-08-2013 16:23, Jean Pereira escreveu:

Flavio, pior que não tem nada no messages mesmo, isso que está me
deixando com a pulga atrás da orelha.


Ora pois...
O messages (caso do CentOS) tem que ter todas as mensagens do kernel 
desde o momento do boot.


Como assim, não tem *nada*?

Bom, melhor explicar.
Nada alem do dia do ultimo boot, sendo ele a 10 dias atrás, quando 
coloquei novamente esta maquina em produção.


Algo "parecido", acontecia com o problema que essa maquina apresentou, e 
que aparentemente foi "resolvido". Nada nos logs de informação de problemas.





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

Re: [pgbr-geral] Travamento


On 08/20/2013 16:37, Flavio Henrique Araque Gurgel wrote:

Em 20-08-2013 16:28, Jean Pereira escreveu:

Bom, melhor explicar.
Nada alem do dia do ultimo boot, sendo ele a 10 dias atrás, quando
coloquei novamente esta maquina em produção.

Algo "parecido", acontecia com o problema que essa maquina apresentou, e
que aparentemente foi "resolvido". Nada nos logs de informação de
problemas.


Olha amigo, então o negócio me parece hardware.
Você disse que não conseguiu "matar" o processo do PostgreSQL. Como 
tentou esse "tiro"? Você ainda tinha acesso ao console, usou ssh, usou 
pg_ctl, usou kill?
Bom, primeiro eu tentei via ssh com o '/etc/init.d/postgresql stop' (o 
arquivo do contrib/), esperei alguns minutos, alguns mesmo, depois vi 
que não tinha geito por ele, e então por via das duvidas fiz o acesso e 
a tentativa direto no terminal do servidor, ai tentei no 'pg_ctl -m 
immediate', aonde também não tive sucesso, por fim fiz um 'kill -9' do 
processo do banco, que no qual também não foi. Não consegui de maneira 
alguma matar o postgres.


Digamos que é o que nós aqui já imaginavamos, mas não custa trocar 
ideias sobre o assunto, a gente cresce com isso.


Obrigado,
Se tiver alguma dica ou sugestão, fica a vontade Flavio.



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

Re: [pgbr-geral] Travamento

2013-08-21 Thread Jean Pereira


On 08/20/2013 22:45, Aldrey Galindo wrote:

Jean,

   Estranho realmente não aparecer nada los logs, como mencionado por 
você. Eu já tive problemas com disco, mais normalmente eles apareciam 
no messages.
   O que recomendo é que caso ocorra o problema novamente, tente 
verificar na hora a estrutura dos discos (multipath -l, pvscan). Pois, 
assim pode vê se nesses momentos ele está se "perdendo".
   Seria bom também ver como está a utilização dos discos com o 'sar 
-d' e a fila de processamento com o 'vmstat 2' (a cada 2 segundos). Se 
tiver com grande utilização dos discos e a fila estiver muito grande, 
aí é indicativo de que não está funcionando bem sua estrutura.



Obrigado pela dica!


Atenciosamente,
Aldrey Galindo



___
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] Travamento

2013-09-03 Thread Jean Pereira


Bom dia,

Somente para dar um retorno...
Não conseguimos detectar nada no hardware até agora, nem mesmo o suporte 
contratado não achou problemas.
Estou levando seriamente a hipótese que o Flavio comentou sobre os 
canais que ligam o servidor com a storage terem dado algum problema.


Mais de todo modo, até o momento não ocorreu mais problemas.

Abraço
Jean Pereira

On 08/21/2013 07:58 AM, Jean Pereira wrote:

On 08/20/2013 22:45, Aldrey Galindo wrote:

Jean,

   Estranho realmente não aparecer nada los logs, como mencionado por 
você. Eu já tive problemas com disco, mais normalmente eles apareciam 
no messages.
   O que recomendo é que caso ocorra o problema novamente, tente 
verificar na hora a estrutura dos discos (multipath -l, pvscan). 
Pois, assim pode vê se nesses momentos ele está se "perdendo".
   Seria bom também ver como está a utilização dos discos com o 'sar 
-d' e a fila de processamento com o 'vmstat 2' (a cada 2 segundos). 
Se tiver com grande utilização dos discos e a fila estiver muito 
grande, aí é indicativo de que não está funcionando bem sua estrutura.



Obrigado pela dica!


Atenciosamente,
Aldrey Galindo



___
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] PANIC: right sibling's left-link doesn't match

2013-09-27 Thread Jean Pereira


On 09/26/2013 07:57 PM, Matheus de Oliveira wrote:




2013/9/26 Adriano Espinoza de Oliveira >


Boa tarde pessoal.


Boa noite... =D


Hje de manhã tivemos "too many clients" no banco, eu não esta na
empresa, e o adm de redes foi lá e derrubou um monte de conexões
do postgres que ele achou q eram antigas...


Bom, a alguns anos atrás, fiz isso também, se não me engano também era 
na versão 8.x (não lembro exato porque faz tempo, talvez seja a 7.x).


Derrubou como? Se foi um "kill -9" é bom dar um "kill -9  `pidof 
cara_que_fez_isso`"... =P



Estou brincando viu, vamos lá ...

O banco ficou inacessível, ele fez um restart do banco, que não
subiu. Teve que apagar o PID na unha e depois o banco subiu...


Ok. Normal...


Depois disso, quando cheguei, notei que o banco estava se
derrubando e subindo sozinho, exibindo essas mensagens:

* 2013-09-26 12:09:25 BRT [18539]: [1-1] db=,user= LOG:  server
process (PID 23040) was terminated by signal 6*
* 2013-09-26 12:09:25 BRT [18539]: [2-1] db=,user= LOG:
 terminating any other active server processes*
*10.11.0.2 2013-09-26 12:09:25 BRT [23043]: [3-1]
db=cimed,user=postgres WARNING:  terminating connection because of
crash of another server process*
*(...)*


E tive um problema muito parecido... como falei, não consigo precisar, 
faz muito tempo...
A solução que eu tive foi que achei um script em um post falando do 
problema e que o mesmo resolveria isso, olhei o script e rodei o mesmo. 
resolveu o meu problema.


Como um velho conhecido meu fala, o kill é o ultimo do ultimo caso. Já 
que você deve ter conexões reservadas ao postgres, e o mesmo consegue 
matar conexão por dentro do banco.


Mais não é o caso agora... vou tentar achar aqui a situação que tive e a 
solução exata, se eu achar eu posto.


Essas mensagens querem dizer que  um dos backends do PostgreSQL 
terminou e os demais pararam também pelo fato deste poder ter 
corrompido a memória compartilhada.




Quando subia, esse era o log:

*(...)*

e sempre precedido dessas msg´s ( note que tive varias ocorrencias
dela)

*10.11.0.2 2013-09-26 12:09:24 BRT [23040]: [3-1]
db=cimed,user=postgres PANIC:  right sibling's left-link doesn't
match*
*(...)*
*10.11.0.2 2013-09-26 15:05:46 BRT [3063]: [15-1]
db=cimed,user=postgres PANIC:  right sibling's left-link doesn't
match*
*
*


Ok. Aqui parece que temos o problema: algum(ns) índice(s) corrompido(s)...


*além da informação de roll back das transações: *
*
10.11.0.2 2013-09-26 17:25:11 BRT [11831]: [4-1]
db=nutracom,user=visao DETAIL:  The postmaster has commanded this
server process to roll back the current transaction and exit,
because another server process exited abnormally and possibly
corrupted shared memory.
(...)

*

Normal...


Pesquisando, vi que poderia ser corrupção de indices...

Derrubei o banco, limitei o acesso dos usuários, e executei o
reindex de todas as tabelas em lote, com script.


Como? Reindexou TODAS as bases?

Durante esse processo, tive o mesmo problema duas vezes, qdo o
indice chegou numa determinada tabela, ao invés de executar o
script em lote, fiz tabela a tabela, e passou do ponto que dava erro.

O reindex de todas as tabelas terminou, e subi o banco novamente...

Duas horas depois, a mesma coisa com o aumento do acesso:
*10.11.0.2 2013-09-26 17:10:37 BRT [11516]: [1-1]
db=cimed,user=postgres PANIC:  right sibling's left-link doesn't
match*
*10.11.0.2 2013-09-26 17:25:10 BRT [13163]: [1-1]
db=cimed,user=postgres PANIC:  right sibling's left-link doesn't
match*
*
*
*Inclusive essa mensagem me preocupou e não tenho idéia do que
pode ser:*
*
10.35.0.2 2013-09-26 18:01:28 BRT [16124]: [1-1]
db=nutracom,user=postgres WARNING:  could not remove relation
1663/105809227/572937579: Arquivo ou diretório não encontrado
10.35.0.2 2013-09-26 18:01:28 BRT [16124]: [2-1]
db=nutracom,user=postgres WARNING:  could not remove relation
1663/105809227/572937581: Arquivo ou diretório não encontrado
10.35.0.2 2013-09-26 18:01:28 BRT [16124]: [3-1]
db=nutracom,user=postgres WARNING:  could not remove relation
1663/105809227/572937583: Arquivo ou diretório não encontrado
10.35.0.2 2013-09-26 18:01:28 BRT [16124]: [4-1]
db=nutracom,user=postgres WARNING:  could not remove relation
1663/105809227/572937585: Arquivo ou diretório não encontrado
10.35.0.2 2013-09-26 18:01:28 BRT [16124]: [5-1]
db=nutracom,user=postgres WARNING:  could not remove relation
1663/105809227/572937586: Arquivo ou diretório não encontrado
10.35.0.2 2013-09-26 18:01:28 BRT [16124]: [6-1]
db=nutracom,user=postgres WARNING:  could not remove relation
1663/105809227/572937588: Arquivo ou diretório não encontrado
10.35.0.2 2013-09-26 18:01:28 BRT [16124

Re: [pgbr-geral] Replicação

2013-12-02 Thread Jean Vichinheski

Essa empresa tem a solução certa pra vc homologada e funciona 100 %
http://www.psmi.com.br/ fala com o Cesar Antonio dos Santos  Eles tem o
Beehive Replicator ! Faz a replicação de banco de dados mantendo uma
matriz e varias filiais com bastante recursos!!!


att,

JEan


Em 2 de dezembro de 2013 16:19, Daviramos Roussenq Fortunato <
daviramo...@gmail.com> escreveu:

> Olá Lista,
>
>   Sou novo por aqui, mas já trabalho a uns 5 anos com Postgresql, já
> pesquisei bastante sobre meu problema, mas ainda não consegui chega a uma
> solução. Vou tentar explicar brevemente o que preciso, e espero que os
> Colaboradores da Lista, possam contribuir meu caso.
>
>Tenho uma Matriz + 4 Filiais, hoje o Banco roda apenas na Matriz e as
> filiais acessam a Matriz via Terminal Service. A filiais ficam em lugares
> distantes sem grande recursos de Internet.
>
>Gostaria de instalar o Banco na Filiais que serviria para executar as
> consultas, e os Inserts fossem enviados para o Banco da Matriz, e o Banco
> da Matriz se atualizaria as filiais.
>
> Não posso fazer isso na APLICAÇÃO, eu preciso que o próprio SGDB
> consiga tratar. Alguém teria uma dica?
>
> --
> Atenciosamente
> Daviramos Roussenq Fortunato
>
> ___
> 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] pg_basebackup para fita

2014-02-05 Thread Jean Pereira


Boa tarde,

Gostaria de saber se é viável e se tem como eu rodar um pg_basebackup e 
mandar direto para a fita (/dev/st0)?


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

Re: [pgbr-geral] pg_basebackup para fita

2014-02-06 Thread Jean Pereira




On 02/05/2014 04:28 PM, Flavio Henrique Araque Gurgel wrote:



> Gostaria de saber se é viável e se tem como eu rodar um 
pg_basebackup e mandar direto para a fita (/dev/st0)?


Sim sem problemas.
O único inconveniente que vejo é que isso demora dependendo do 
tamanho, mas aí é caso a caso.



Legal.. é somente 120 Gb, pequeno ainda.
Hoje efetuo o backup e depois mando para a fita.
Posso estar enganado, mais acho que mandar direto fica mais rápido. É LTO-3

Flavio, eu não sei exatamente o comando, e também não achei tal exemplo 
na internet, poderia me ajudar com o mesmo?


Obrigado.


[] s



___
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] pg_basebackup para fita

2014-02-06 Thread Jean Pereira



On 02/05/2014 04:52 PM, Douglas Fabiano Specht wrote:




Em 5 de fevereiro de 2014 16:28, Flavio Henrique Araque Gurgel 
mailto:fha...@gmail.com>> escreveu:



> Gostaria de saber se é viável e se tem como eu rodar um
pg_basebackup e mandar direto para a fita (/dev/st0)?

Sim sem problemas.
O único inconveniente que vejo é que isso demora dependendo do
tamanho, mas aí é caso a caso.

[] s


___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br

https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral


nao seria melhor vc colocar para fazer o bckup um uma partição do 
disco, e ter um shell script que copie ele para a fita?

Praticamente faço isso hoje.


--

Douglas Fabiano Specht


___
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] Opinião - Amazon

2014-06-27 Thread Jean Pereira


Boa tarde,

Gostaria de uma opinião de vocês.

Temos um sistema que gerencia a saúde publica de alguns municípios do 
pais, atende a +- 2 milhões de pessoas. Roda 24/7 em todos os postos de 
saúde, UPA 24 e pronto socorros de alguns clientes. O sistema em si já 
ultrapassa as 9 milhões de transações dia.


Situação é a seguinte, hoje tenho uma estrutura redundante, de 
datacenter e servidores, e no qual tenho um gasto de +- R$ 6500,00 (+ a 
depreciação) - contando tudo. Sendo a estrutura master com redundância 
aqui na empresa, e mais uma redundância em outro DC.


Nessa situação, eu estou sendo questionado sobre a amazon, mais por 
causa do custo, sendo que eles na teoria fornecem tudo redundante e com 
SLA de 99.95% ao mês (se não me engano), que na teoria também o custo é 
menor.


Hoje minha SLA dos servidores está em 99.997% e do BGP em 99.96%

Gostaria da opinião de quem usa, ou de quem já usou, ou até mesmo de 
quem trabalha com situação parecida de disponibilidade.

Os contratos são com SLA, e alta demanda, e para piorar, sem "fidelidade".


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

Re: [pgbr-geral] Opinião - Amazon

2014-06-27 Thread Jean Pereira



On 06/27/2014 02:00 PM, Flávio Granato wrote:

On 06/27/2014 01:53 PM, Jean Pereira wrote:

Boa tarde,

Gostaria de uma opinião de vocês.

Temos um sistema que gerencia a saúde publica de alguns municípios do
pais, atende a +- 2 milhões de pessoas. Roda 24/7 em todos os postos
de saúde, UPA 24 e pronto socorros de alguns clientes. O sistema em si
já ultrapassa as 9 milhões de transações dia.

Situação é a seguinte, hoje tenho uma estrutura redundante, de
datacenter e servidores, e no qual tenho um gasto de +- R$ 6500,00 (+
a depreciação) - contando tudo. Sendo a estrutura master com
redundância aqui na empresa, e mais uma redundância em outro DC.

Nessa situação, eu estou sendo questionado sobre a amazon, mais por
causa do custo, sendo que eles na teoria fornecem tudo redundante e
com SLA de 99.95% ao mês (se não me engano), que na teoria também o
custo é menor.

Hoje minha SLA dos servidores está em 99.997% e do BGP em 99.96%

Gostaria da opinião de quem usa, ou de quem já usou, ou até mesmo de
quem trabalha com situação parecida de disponibilidade.
Os contratos são com SLA, e alta demanda, e para piorar, sem
"fidelidade".

Uma sugestão que acho importantíssimo você ter uma definição é sobre o
local de armazenamento dos dados. Um professor meu comentou que um
serviço de proteção ao crédito utiliza infra virtualizada por uma dessas
grandes mas a justiça brasileira orientou a deixar os dados no Brasil
por questões jurídicas.

Sim, mais na teoria, eles tem em SP não?
Essa questão para mim é primordial, já que são prontuários de pacientes 
(por exemplo), que em processos (que não são poucos, ainda mais contra a 
saúde pública) são requeridos/utilizados, etc..


___
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] Case com Zebedee

2014-07-23 Thread Jean - GeControl

Pessoal,apenas compartilhando com a lista: estou acessando o banco de dados Postgresql através da internet, através de um link dedicado de 2Mbps do lado host e client. Pra melhorar o desempenho, coloquei o Zebedee pra fazer o tunneling, com compactação de pacotes. Percebi que a melhor no Fetch das consultas ficou na casa dos 65%, em média. Visivelmente, no manuseio do sistema ERP, o ganho foi considerável.Espero que o case sirva pra outros usuários.Jean DominguesSócio-ProprietárioGecontrol Consultoria e Sistemas.___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Case com Zebedee

2014-07-25 Thread Jean - GeControl

>> Utilizo Zebedee a um bom tempo.. é muito bom! Ele cria um tunel entre >> o server e o client e toda informação que trafega neste tunel é >> compactada, deixando assim a comunicação entre cliente/servidor mais >> rápida.>>>Uma pergunta de leigo: qual a diferença, em termos de performance, entre >uma ferramenta deste segmento e um túnel VPN sobre UDP compactado, como >por exemplo, o OpenVPN?Tá aí, realmente não sei. Quem usa podia por aqui o case, sobre a diferença de performance, assim como Postgresql com SSL. O zebedee é muito leve, e no meu caso, não usei criptografia. Mas acredito que outras soluções do gênero ofereçam o mesmo benefício.Jean Domingues - GECONTROL___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Case com Zebedee

2014-07-28 Thread Jean - GeControl

Boa tarde Jean,

Em 25-07-2014 08:32, Jean - GeControl
escreveu:

.x_notviscode, .notviscode { visibility: hidden; width: 0px; height: 0px; display: none; }>>
Utilizo Zebedee a um bom tempo.. é muito bom! Ele cria um tunel
entre
>> o server e o client e toda informação que trafega neste
tunel é
>> compactada, deixando assim a comunicação entre
cliente/servidor mais
>> rápida.
>>
>Uma pergunta de leigo: qual a diferença, em termos de
performance, entre
>uma ferramenta deste segmento e um túnel VPN sobre UDP
compactado, como
>por exemplo, o OpenVPN?

Tá aí, realmente não sei. Quem usa podia por aqui o case, sobre
a diferença de performance, assim como Postgresql com SSL. O
zebedee é muito leve, e no meu caso, não usei criptografia. Mas
acredito que outras soluções do gênero ofereçam o mesmo
benefício.

Aproveitei alguns minutos do almoço e fiz uma avaliação rápida
cruzando acesso direto e VPN com e sem SSL. Utilizei o seguinte
cenário:

Consulta que me retorna 1.642 registros com aprox. 2MB de
tráfego de texto plano;

O servidor encontra-se a 30 saltos (via traceroute) de onde
estou no momento. Executei os comandos em uma maquina linux com
conexão ADSL GVT;
Como estamos em um horário de produção e a ADSL nesses horário
pode ser afetada, a repetição do comando gerou alguns dados com
distorções significativas. então capturei o valor mais próximo
entre eles de um total de 10 execuções com intervalo de 2
segundos entre as execuções;
A consulta executada em localhost no servidor do banco tem um
tempo de 10.998 ms;
Para não considerar o tempo de autenticação e validação da
senha, seja manual, por software ou via .pgpass, alterei os
acessos do usuário para TRUST para os IPs utilizados (público de
minha estação e da VPN).

##Execução com IP público

#PSQL COM SSL habilitado
$ export SSLMODE=required
$ time psql portal -U daniel -h -c "select * from
tb_pedidos where fk_cliente = " > /dev/null

real 0m1.823s
user 0m0.089s
sys 0m0.009s

#PSQL SEM SSL habilitado
$ export SSLMODE=disable
$ time psql portal -U daniel -h -c "select * from
tb_pedidos where fk_cliente = " > /dev/null

real 0m2.072s
user 0m0.090s
sys 0m0.012s

##Execução em VPN com comp-lzo habilitado

#PSQL COM SSL habilitado
$ export SSLMODE=required
$ time psql portal -U daniel -h 10.1.0.10 -c "select * from
tb_pedidos where fk_cliente = " > /dev/null

real 0m1.861s
user 0m0.090s
sys 0m0.010s

##PSQL SEM SSL habilitado

$ export SSLMODE=disable
$ time psql portal -U daniel -h 10.1.0.10 -c "select * from
tb_pedidos where fk_cliente = " > /dev/null

real 0m1.785s
user 0m0.086s
sys 0m0.013s

Uma vez que o OpenVPN já é criptografado e esta com compactação
habilitada, a melhor situação foi VPN com conexão ao banco SEM SSL.
Apesar da diferença ser muito baixa.

Espero que ajude.

Att,
| Daniel Cordeiro de Morais Neto
| Diretor de TI - Portal de Cotações e-Compras
| Sócio-diretor ADM Soluções em Informática LTDADaniel... creio que o mais importante nesses teste de tráfego seja o fetch time, ou seja, o tempo que demora para o dadotrafegar para o lado client. O tempo de execução está relacionado a cache de dados. Não entendi se você levou isso em conta noteste acima.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Aprender mais sobre PostgreSQL

2014-09-03 Thread Jean Pereira

Aqui (http://www.postgresql.org/docs/books/) você pode ver alguns dos 
livros sobre PostgreSQL.


On 09/02/2014 09:09 PM, Roger Eduardo wrote:

Eu também já pensei em perguntar isso de forma mais ampla.
Quais são os livros que vocês leram e recomendam sobre Postgresql?

Att,

Roger Eduardo.
+55 11 973 222 198


2014-09-02 20:07 GMT-03:00 Fabio Romanzini >:


Boa noite Pessoal,

Estou mexendo com o PostgreSQL faz 4 anos já, porém estou sempre a
procura de aprender mais sobre o Postgres, gostaria de saber se
alguém sabe ou possui algum documento que possa ser compartilhado
para estudar?


-- 
/*Fabio Romanzini*/


___
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] Backup | Restore | PITR

2014-10-28 Thread Jean Pereira


Bom dia,

Sugiro a leitura do livro "Instant PostgreSQL Backup and Restore 
How-to", gostei muito do mesmo, e além do que já foi recomendado aqui na 
lista também.



On 10/28/2014 08:44 AM, Fernando Cambiaghi wrote:

Bom dia Pessoal,

Sou novo na lista, tenho acompanhado alguns emails e fico 
impressionado com a dedicação do pessoal em responder a todas as 
questões com o nível incrível de detalhe. Parabéns.


Fiz um curso na Dextra em SP a uns dois anos, e estou trabalhando para 
migrar um banco de dado "X" para PostgreSQL. ( Estou utilizando 
windows 7 com versão 9.3.5 do PostgreSQL.


O tamanho da minha base de dados é relativamente pequena ( 231 tabelas 
ocupando um total entre 4GB e 5GB ).


Pois bem, a migração do bando está feita ( Homologando ), e agora 
estou me apegando a entender a parte de Backup e Restore, mas estou 
tendo muita dificuldade, mas creio que por falta de entendimento meu.


No meu ambiente atual, faço backup completo do banco de dados todas as 
noites, com o banco online e em uso, e tenho o log de transações para, 
em caso de catástrofe*, posso pegar o último backup completo e aplicar 
o log atual ( Tem todo um processo de transcrever e ler o mesmo para o 
banco ).



Com o PostgreSQL, entendi que para ter um ambiente igual, para em caso 
de catástrofe poder recuperar os dados para o mais atual possível, eu 
devo efetuar um backup completo diariamente ( estou fazendo isso com o 
pg_dump ) e manter os archives ativados [1]. Até aí creio que fiz tudo 
certo.


Para simular uma catástrofe, eu desligo o computador com transações 
ocorrendo no banco, e quando ligo novamente, não consigo nem subir o 
serviço do postgres, aí é que começo a apanhar.


Desinstalo e reinstalo o postgres, mesma versão, volto o backup 
(pg_restore) e sigo as instruções de [1], mas não consigo. Quando digo 
não consigo, é estou fazendo algo errado, não volta os archives.


Gostaria de saber se alguém tem um passo a passo mais detalhado de 
como fazer isso, pois não quero colocar o banco postgres em produção 
sem ter domínio de como restaurar um backup em caso de problemas.


[1] http://www.postgresql.org/docs/9.3/static/continuous-archiving.html

*Qualquer tipo de perda de dados ou do próprio banco de dados.

Perdoem por me alongar tanto, mas queria apresentar minha situação e 
apresentação ao grupo.


Agradeço a todos pela compreensão.

Fernando Luís Cambiaghi
/cambia...@gmail.com /



___
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] Informação sobre conversão de tipo automática.

2014-12-17 Thread Jean Pereira


Pessoal, gostaria de saber se isto é um bug ou é algo "normal"

Crio a tabela

   CREATE TEMP table table_a (field_a time);

Efetuo a inserção de um dado, sendo que utilizo o current_timestamp, e o 
banco efetua a conversão automática para time na hora que insere.


   insert into table_a values (current_timestamp);

Mas se eu efetuo um simples select utilizando tambem o current_timestamp

   select * from table_a where field_a = current_timestamp;
   ERROR:  operator does not exist: time without time zone = timestamp
   with time zone
   LINE 1: select * from table_a where field_a = current_timestamp;
^
   HINT:  No operator matches the given name and argument type(s). You
   might need to add explicit type casts.


Sei que eu deveria efetuar a comparação com time, mais detectamos tal 
situação, aonde um campo que era para ser timestamp está como time, e as 
gravações ocorreram normalmente, aonde eu acredito que não deveriam 
acontecer também como no select.
O campo é de uma tabela de log, praticamente não utilizado e por isso 
não percebemos o erro.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Informação sobre conversão de tipo automática.

2014-12-17 Thread Jean Pereira



On 12/17/2014 02:42 PM, Flavio Henrique Araque Gurgel wrote:

Pessoal, gostaria de saber se isto é um bug ou é algo "normal"

Crio a tabela

CREATE TEMP table table_a (field_a time);

Efetuo a inserção de um dado, sendo que utilizo o current_timestamp, e o
banco efetua a conversão automática para time na hora que insere.

insert into table_a values (current_timestamp);

Mas se eu efetuo um simples select utilizando tambem o current_timestamp

select * from table_a where field_a = current_timestamp;
ERROR:  operator does not exist: time without time zone = timestamp
with time zone
LINE 1: select * from table_a where field_a = current_timestamp;
 ^
HINT:  No operator matches the given name and argument type(s). You
might need to add explicit type casts.


É normal.
A conversão de timestamp para hora é trivial e está na tabela de 
conversões de tipos, mas o contrário não e não vale para comparações. 
Note que isso poderia te levar a erro grave de semântica.



Sei que eu deveria efetuar a comparação com time, mais detectamos tal
situação, aonde um campo que era para ser timestamp está como time, e as
gravações ocorreram normalmente, aonde eu acredito que não deveriam
acontecer também como no select.
O campo é de uma tabela de log, praticamente não utilizado e por isso
não percebemos o erro.


Simplesmente inclua a conversão no seu SELECT:
select * from table_a where field_a = current_timestamp::time;

Ou use outra função, a current_time:
select * from table_a where field_a = current_time;


Beleza, sobre a conversão tudo bem, eu só achei estranho tal situação.

[]s
Flavio Gurgel
___
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] Informação sobre conversão de tipo automática.

2014-12-18 Thread Jean Pereira



On 12/17/2014 06:08 PM, Matheus de Oliveira wrote:


2014-12-17 14:35 GMT-02:00 Jean Pereira <mailto:ad...@olostech.com>>:


CREATE TEMP table table_a (field_a time);

Efetuo a inserção de um dado, sendo que utilizo o
current_timestamp, e o banco efetua a conversão automática para
time na hora que insere.

insert into table_a values (current_timestamp);

Mas se eu efetuo um simples select utilizando tambem o
current_timestamp

select * from table_a where field_a = current_timestamp;


Bem, existe uma diferença básica. Só para exemplificar o conceito, no 
PostgreSQL as conversões de tipos são tratadas por funções, sendo que 
existe três tipos de conversões:


- explícitas: são aquelas que você deixa claro, exemplo: 
CAST(current_timestamp AS time) ou current_timestamp::time
- implícitas: (em inglês chamados de "implicit casts") são aqueles 
literalmente implícitos, por exemplo a conversão de "int" para 
"bigint", um "int" sempre cabe num "bigint", logo essa conversão pode 
ser feita sem perda alguma, *SEMPRE*
- implícitas no assinalamento: (em inglês "assignment casts") são 
usadas em operações de atribuição, por exemplo, num INSERT, num UPDATE 
ou ALTER TABLE ... ALTER ... TYPE (na verdade só conheço esses três, 
não sei se tem mais).


Sabendo disso fica fácil identificar o seu caso. No INSERT o 
PostgreSQL irá procurar por um "implict cast" ou "assignment cast" de 
"timestamptz" para "time", existindo (e existe) este será usado. Já no 
SELECT o PostgreSQL irá procurar primeiro por um operador de igualdade 
entre os dois tipos em questão, se este não existir (e não existe) aí 
sim ele irá procurar por um "implicit cast", que no caso também não 
existe, logo o erro (não tenho certeza se a ordem é essa operador 
depois cast, mas creio que seja).


Só pra deixar documentado, se for no psql e executar `\dC 'timestamp 
with time zone'` irá obter:


postgres=# \dC 'timestamp with time zone'
  List of casts
 Source type | Target type |  
Function   |   Implicit?

-+-+-+---
 abstime | timestamp with time zone| 
timestamptz | yes
 date| timestamp with time zone| 
timestamptz | yes
 timestamp without time zone | timestamp with time zone| 
timestamptz | yes
 timestamp with time zone| abstime | 
abstime | in assignment
 timestamp with time zone| date| 
date| in assignment
 timestamp with time zone| timestamp without time zone | 
timestamp   | in assignment
 timestamp with time zone| timestamp with time zone| 
timestamptz | yes
 timestamp with time zone| time without time zone  | 
time| in assignment
 timestamp with time zone| time with time zone | 
timetz  | in assignment

(9 rows)

A última linha é o "cast" que foi usado no seu comando INSERT. 
Resumindo, os hackers do PostgreSQL acharam que seria razoável a 
conversão de "timestamptz" para "time" de forma implícita, mas somente 
numa atribuição.


Espero que tenha esclarecido.


Beleza, obrigado pelas informações.

Atenciosamente,
--
Matheus de Oliveira
Analista de Banco de Dados
Dextra Sistemas - MPS.Br nível F!
www.dextra.com.br/postgres <http://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


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

Re: [pgbr-geral] Configurar acessos no arquivos pg_hba.conf

2015-01-28 Thread Jean - GeControl

Crie mais que uma linha no pg_hba.conf.Jean DominguesSócio-ProprietárioGecontrol Consultoria e Sistemas.De: "Matheus Saraiva" Em: Terça-feira 27 de Janeiro de 2015 11:17,  Para: pgbr-geral@listas.postgresql.org.brAssunto: [pgbr-geral] Configurar acessos no arquivos pg_hba.confBem, eu configurei o pg_hba.conf para liberar o acesso apenas para umip, [IP]/32, porém, eu quero também liberar o acesso via localhost. Comofazer?___pgbr-geral mailing listpgbr-geral@listas.postgresql.org.brhttps://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 postgres


On 02/10/2015 09:35 AM, Leandro wrote:
Pessoal, utilizo a replicação sincrona do postgresql  versão 9.2 e 
depois de um tempo em execução a mesma apresentou problemas na replica 
conforme logs abaixo:


WARNING,01000,"page 1186 of relation base/91198868/91199917 is 
uninitialized","xlog redo vacuum: rel 1663/91198868/91199917; blk 
1201, lastBlockVacuumed 0"""
PANIC,XX000,"WAL contains references to invalid pages","xlog redo 
vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0"""


sendo que o master da replicação parece estar tudo normal,
alguem já passou por situação parecida?

Hoje as 9:50 começou este problema para mim, estou procurando uma 
alternativa também.

Versão 9.3.6

   2015-02-10 09:58:04 BRST [4882]: [6-1] user=,db= WARNING:  page 196
   of relation base/26790/24953388 is uninitialized
   2015-02-10 09:58:04 BRST [4882]: [7-1] user=,db= CONTEXT:  xlog redo
   visible: rel 1663/26790/24953388; blk 196
   2015-02-10 09:58:04 BRST [4882]: [8-1] user=,db= PANIC:  WAL
   contains references to invalid pages
   2015-02-10 09:58:04 BRST [4882]: [9-1] user=,db= CONTEXT:  xlog redo
   visible: rel 1663/26790/24953388; blk 196
   2015-02-10 09:58:04 BRST [4880]: [6-1] user=,db= LOG:  startup
   process (PID 4882) was terminated by signal 6: Aborted
   2015-02-10 09:58:04 BRST [4880]: [7-1] user=,db= LOG:  terminating
   any other active server processes


como posso verificar que objeto que está apresentando o problema?


___
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 postgres



On 02/10/2015 10:51 AM, Jean Pereira wrote:

On 02/10/2015 09:35 AM, Leandro wrote:
Pessoal, utilizo a replicação sincrona do postgresql  versão 9.2 e 
depois de um tempo em execução a mesma apresentou problemas na 
replica conforme logs abaixo:


WARNING,01000,"page 1186 of relation base/91198868/91199917 is 
uninitialized","xlog redo vacuum: rel 1663/91198868/91199917; blk 
1201, lastBlockVacuumed 0"""
PANIC,XX000,"WAL contains references to invalid pages","xlog redo 
vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 0"""


sendo que o master da replicação parece estar tudo normal,
alguem já passou por situação parecida?

Hoje as 9:50 começou este problema para mim, estou procurando uma 
alternativa também.

Versão 9.3.6

2015-02-10 09:58:04 BRST [4882]: [6-1] user=,db= WARNING:  page
196 of relation base/26790/24953388 is uninitialized
2015-02-10 09:58:04 BRST [4882]: [7-1] user=,db= CONTEXT:  xlog
redo visible: rel 1663/26790/24953388; blk 196
2015-02-10 09:58:04 BRST [4882]: [8-1] user=,db= PANIC:  WAL
contains references to invalid pages
2015-02-10 09:58:04 BRST [4882]: [9-1] user=,db= CONTEXT:  xlog
redo visible: rel 1663/26790/24953388; blk 196
2015-02-10 09:58:04 BRST [4880]: [6-1] user=,db= LOG:  startup
process (PID 4882) was terminated by signal 6: Aborted
2015-02-10 09:58:04 BRST [4880]: [7-1] user=,db= LOG: terminating
any other active server processes

Fiz um backup da base no slave, e fiz uma copia do arquivo que 
apresentava erro, ou seja, copiei ele do master pro slave e dei start. A 
principio está funcionando... vou monitorar o mesmo, qualquer coisa 
também eu volto o bkp.



como posso verificar que objeto que está apresentando o problema?


___
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 postgres



On 02/10/2015 12:08 PM, Flavio Henrique Araque Gurgel wrote:

Fiz um backup da base no slave, e fiz uma copia do arquivo que
apresentava erro, ou seja, copiei ele do master pro slave e dei start. A
principio está funcionando... vou monitorar o mesmo, qualquer coisa
também eu volto o bkp.


Isso é um perigo enorme e você pode ter inconsistências no escravo.
Refazer o escravo do zero é o mais seguro.


Sim, mas por isso mesmo eu fiz um backup do escravo antes.
Estou verificando a situação, já que esse escravo está "distante" e vai 
depender do link para refazer o mesmo, e também ele é a ultima da ultima 
instancia.

Ele faz parte da redundancia de DC, e eu tenho mais um slave aqui.

[]s
Flavio Gurgel
___
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 postgres



On 02/10/2015 11:58 AM, Flavio Henrique Araque Gurgel wrote:

On 02/10/2015 09:35 AM, Leandro wrote:

Pessoal, utilizo a replicação sincrona do postgresql  versão 9.2 e
depois de um tempo em execução a mesma apresentou problemas na replica
conforme logs abaixo:

WARNING,01000,"page 1186 of relation base/91198868/91199917 is
uninitialized","xlog redo vacuum: rel 1663/91198868/91199917; blk
1201, lastBlockVacuumed 0"""
PANIC,XX000,"WAL contains references to invalid pages","xlog redo
vacuum: rel 1663/91198868/91199917; blk 1201, lastBlockVacuumed 
0"""


sendo que o master da replicação parece estar tudo normal,
alguem já passou por situação parecida?


Qual a versão exata? É a última da série 9.2?
Há um bug conhecido e, dependendo da sua versão, pode não estar 
corrigido.

A ordem é:
1) atualize os binários do PostgreSQL para 9.2.10 (no seu caso)
2) refaça o escravo (novo pg_basebackup).


Hoje as 9:50 começou este problema para mim, estou procurando uma
alternativa também.
Versão 9.3.6


Não é a mesma versão do outro colega. Mas refaça seu pg_basebackup e 
recrie o novo escravo.
Embora sua versão esteja em dia, se o pg_basebackup foi feito com a 
versão bugada, o erro pode acontecer tardiamente.

Isso eu não sabia, talvez seja essa minha situação então.




2015-02-10 09:58:04 BRST [4882]: [6-1] user=,db= WARNING: page 196
of relation base/26790/24953388 is uninitialized
2015-02-10 09:58:04 BRST [4882]: [7-1] user=,db= CONTEXT: xlog redo
visible: rel 1663/26790/24953388; blk 196
2015-02-10 09:58:04 BRST [4882]: [8-1] user=,db= PANIC:  WAL
contains references to invalid pages
2015-02-10 09:58:04 BRST [4882]: [9-1] user=,db= CONTEXT: xlog redo
visible: rel 1663/26790/24953388; blk 196
2015-02-10 09:58:04 BRST [4880]: [6-1] user=,db= LOG: startup
process (PID 4882) was terminated by signal 6: Aborted
2015-02-10 09:58:04 BRST [4880]: [7-1] user=,db= LOG: terminating
any other active server processes


como posso verificar que objeto que está apresentando o problema?


Outra pergunta, abra outro assunto, não sequestre.
Você encontra todos os objetos na tabela pg_class, no seu caso filtre 
pelo relfilenode :

SELECT relname FROM pg_class WHERE relfilenode = 24953388;

A consulta vai te retornar o nome da tabela ou índice corrompido.

[]s
Flavio Gurgel
___
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] Timeout Conexão

2015-03-25 Thread Jean - GeControl

Já vi esse erro também, e era problema com o antivírus, no caso, o F-Secure.Jean DominguesSócio-ProprietárioGecontrol Consultoria e Sistemas.De: "Douglas Fabiano Specht" Em: Segunda-feira 23 de Março de 2015 14:56,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] Timeout ConexãoEm 23 de março de 2015 14:32, Mauro Fonseca  escreveu:Tive algumas experiências com esta mensagem e geralmente era erro falha na rede do usuário.Em 23 de março de 2015 14:01, Pedro B. Alves  escreveu:Qual erro é apresentado? Algo nos logs do servidor também?Nos logs não tem nada. 
___
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
Amigo,deixe um ping -t para o ip do servidor e veja se nao vai cair a conexao neste momento da mensagem.-- Douglas Fabiano Specht

___pgbr-geral mailing listpgbr-geral@listas.postgresql.org.brhttps://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] could not send data to client: Conexão fechada pela outra ponta

2015-11-04 Thread Jean - GECONTROL

Tenho esse problema num cliente, e a culpa é do F-Secure... não consegui resolver com exceções.Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.De: "Flavio Henrique Araque Gurgel" Em: Terça-feira 03 de Novembro de 2015 11:42,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] could not send data to client: Conexão fechada pela outra ponta> Acredito mais na hipótese de que algo entre aplicação de banco tenha> derrubado a conexão, firewall, antivírus, talvez IPV6 (pesquisando vi> posts em java+postgresql falando nesse assunto) ou algo assim. Pois> não são todas as máquinas que perdem a conexão, de 20 estações umas> 3,4 apresentam esse problema.Verifique os endereços MAC das placas de rede dessas 3, 4 máquinas e veja se não há conflito.Era comum uma época comprarmos placas OEM e elas terem... MAC iguais.Tente também fazer arping na sua rede e verificar se duas máquinas não respondem juntas.[]sFlavio Gurgel___pgbr-geral mailing listpgbr-geral@listas.postgresql.org.brhttps://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] Problema com campo numeric

2015-12-23 Thread Jean - GECONTROL

Esses dias eu tive problema num cliente, que tentava editar um registro, e colocar num campo numeric(18,4) o valor 0.2523. Tentei pela aplicação, e depois direto, pelo PgManager, e o campo não aceitava o valor, que ficava 0.2520. Olhar na trigger, e única referencia ao campo era um campo = coalesce(campo,0). Editei o valor para 0.2524 e aceitou. Ai tenteni novamente por o valor 0.2523, e ai aceitou. Não sei dizer o que houve. A versão do Pg é 9.3.10 64 bits rodando no Windows Server 2008 R2.Alguém já teve algum problema parecido?Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Problema com campo numeric

Eu editei no grid. Mas é estranho o comportamento, tanto na aplicação como no grid. Não testei executando uma instrução SQL.De: "Glauco Torres" Em: Quarta-feira 23 de Dezembro de 2015 16:42,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] Problema com campo numericNo dia 23 de dezembro de 2015 às 16:12, Jean - GECONTROL <j...@gecontrolsistemas.com.br> escreveu:Esses dias eu tive problema num cliente, que tentava editar um registro, e colocar num campo numeric(18,4) o valor 0.2523. Tentei pela aplicação, e depois direto, pelo PgManager, e o campo não aceitava o valor, que ficava 0.2520. Olhar na trigger, e única referencia ao campo era um campo = coalesce(campo,0). Editei o valor para 0.2524 e aceitou. Ai tenteni novamente por o valor 0.2523, e ai aceitou. Não sei dizer o que houve. A versão do Pg é 9.3.10 64 bits rodando no Windows Server 2008 R2.Alguém já teve algum problema parecido? Eu, não :|Qual era o retorno que você tinha? numeric no PgManager não é . (ponto) é , (virgula) será que não era isso?-Glauco Torres 

___pgbr-geral mailing listpgbr-geral@listas.postgresql.org.brhttps://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] Problema com campo numeric

Então, estranho esse comportamento.Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.De: "Emerson da Silva Chalegre" Em: Quarta-feira 23 de Dezembro de 2015 17:13,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] Problema com campo numericEm funcões e triggers de vez em quando tenho problema parecido, e com isso pego o valor e multiplico 1..Tente assim, pode ser que resolva.(0.2523*1.)Em 23 de dezembro de 2015 16:42, Glauco Torres <torres.gla...@gmail.com> escreveu:No dia 23 de dezembro de 2015 às 16:12, Jean - GECONTROL <j...@gecontrolsistemas.com.br> escreveu:Esses dias eu tive problema num cliente, que tentava editar um registro, e colocar num campo numeric(18,4) o valor 0.2523. Tentei pela aplicação, e depois direto, pelo PgManager, e o campo não aceitava o valor, que ficava 0.2520. Olhar na trigger, e única referencia ao campo era um campo = coalesce(campo,0). Editei o valor para 0.2524 e aceitou. Ai tenteni novamente por o valor 0.2523, e ai aceitou. Não sei dizer o que houve. A versão do Pg é 9.3.10 64 bits rodando no Windows Server 2008 R2.Alguém já teve algum problema parecido? Eu, não :|Qual era o retorno que você tinha? numeric no PgManager não é . (ponto) é , (virgula) será que não era isso?-Glauco Torres 

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
___pgbr-geral mailing listpgbr-geral@listas.postgresql.org.brhttps://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] Problema com campo numeric

Entao... certeza... numeric(18,4).Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.De: "Matheus de Oliveira" Em: Quinta-feira 24 de Dezembro de 2015 12:57,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] Problema com campo numeric2015-12-23 17:12 GMT-02:00 Emerson da Silva Chalegre <emerchale...@gmail.com>:Em funcões e triggers de vez em quando tenho problema parecido, e com isso pego o valor e multiplico 1..Tente assim, pode ser que resolva.(0.2523*1.)Isso não era pra acontecer se você estiver usando apenas tipo NUMERIC, tem certeza que não tem nenhum double precision ou real (a.k.a. float8 e float4) envolvidos nessas operações? (a mesma pergunta vale para o OP).Atenciosamente,-- Matheus de Oliveira

___pgbr-geral mailing listpgbr-geral@listas.postgresql.org.brhttps://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] Dúvida sobre postgres_fdw

Pessoal, alguém sabe dizer se é possível executar uma query diretamente num banco de dados externo, sem ter que criar uma foreign table, usando postgres_fdw?Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Dúvida sobre postgres_fdw

Que pena.Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.De: "Flavio Henrique Araque Gurgel" Em: Terça-feira 05 de Janeiro de 2016 15:43,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] Dúvida sobre postgres_fdw> Pessoal, alguém sabe dizer se é possível executar uma query diretamente> num banco de dados externo, sem ter que criar uma foreign table, usando> postgres_fdw?Não.[]sFlavio Gurgel___pgbr-geral mailing listpgbr-geral@listas.postgresql.org.brhttps://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] Dúvida sobre postgres_fdw

Preferia evitar. É uma pena. Valeu.Jean DominguesSócio-ProprietárioGECONTROL Consultoria e Sistemas.De: "Rafael Fialho" Em: Terça-feira 05 de Janeiro de 2016 15:45,  Para: pgbr-geral@listas.postgresql.org.brAssunto: Re: [pgbr-geral] Dúvida sobre postgres_fdwEm 5 de janeiro de 2016 15:41, Jean - GECONTROL <j...@gecontrolsistemas.com.br> escreveu:Pessoal, alguém sabe dizer se é possível executar uma query diretamente num banco de dados externo, sem ter que criar uma foreign table, usando postgres_fdw?Caso seja uma possibilidade, poderia utilizar dblink.[]'s 
___pgbr-geral mailing listpgbr-geral@listas.postgresql.org.brhttps://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] Dúvida sobre postgres_fdw