Pessoal está parcialmente resolvido meu problema, não postei a resposta antes por falta de tempo mesmo. Na madrugada de quinta para sexta-feria não tive tempo fazer o dump e o restore, até tentei, mas a janela de tempo era curta e os sistema tinha q voltar as 06:00hs, então optei por tentar o reindex total, inclusive das tabelas do sistema, e resolveu. Fiz base a base e de lá pra cá está tudo bem, o servidor não está caindo mais.
Mas tenho alguns questionamentos: Hoje vi a seguinte mensagem hoje, então suponho que ainda tenho algum problema com indices, alguma dica? 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [1-1] db=nutracom,user=postgres WARNING: could not remove relation 1663/105809227/572918907: Arquivo ou diretório não encontrado 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [2-1] db=nutracom,user=postgres WARNING: could not remove relation 1663/105809227/572918903: Arquivo ou diretório não encontrado 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [3-1] db=nutracom,user=postgres WARNING: could not remove relation 1663/105809227/572918901: Arquivo ou diretório não encontrado 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [4-1] db=nutracom,user=postgres WARNING: could not remove relation 1663/105809227/572918899: Arquivo ou diretório não encontrado 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [5-1] db=nutracom,user=postgres WARNING: could not remove relation 1663/105809227/572918894: Arquivo ou diretório não encontrado 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [6-1] db=nutracom,user=postgres WARNING: could not remove relation 1663/105809227/572918896: Arquivo ou diretório não encontrado 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [7-1] db=nutracom,user=postgres WARNING: could not remove relation 1663/105809227/572918898: Arquivo ou diretório não encontrado 10.11.0.2 2013-09-30 13:08:59 BRT [24107]: [8-1] db=nutracom,user=postgres WARNING: could not remove relation 1663/105809227/572918892: Arquivo ou diretório não encontrado Durante o reindex, utilizando o comando " reindexdb -a", o reindex foi interrompido com a msg abaixo, passei a reindexar base a base e tudo bem, até chegar em uma determinada tabela, que não sei qual é, ele foi interrompido. Provavelmente é algum lixo ou backup pontual de um select ou coisa assim que foi feita no banco, mas como posso identificar essa tabela? [local] 2013-09-27 03:48:32 BRT [11290]: [290-1] db=cimed,user=postgres NOTICE: table "itens_faltas_pcp" was reindexed [local] 2013-09-27 03:48:32 BRT [11290]: [291-1] db=cimed,user=postgres NOTICE: table "dash_board_vendas_local" was reindexed [local] 2013-09-27 03:48:32 BRT [11290]: [292-1] db=cimed,user=postgres ERROR: could not create unique index [local] 2013-09-27 03:48:32 BRT [11290]: [293-1] db=cimed,user=postgres DETAIL: Table contains duplicated values. Agradeço a todos, Adriano Espinoza Em 30 de setembro de 2013 13:13, Adriano Espinoza de Oliveira < [email protected]> escreveu: > > > > Em 29 de setembro de 2013 09:51, Matheus de Oliveira < > [email protected]> escreveu: > > >> >> >> 2013/9/27 Jean Pereira <[email protected]> >> >>> On 09/26/2013 07:57 PM, Matheus de Oliveira wrote: >>> >>> >>> >>> >>> 2013/9/26 Adriano Espinoza de Oliveira <[email protected]> >>> >>>> 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* >>>> *(...)* >>>> >>>> >>> (...) >>> >>> >>> Como um velho conhecido meu fala, o kill é o ultimo do ultimo caso. >>> >> >> Na verdade o kill em si não é tão problemático assim, você pode, >> tranquilamente usar um `kill -SIGTERM` num backend do postgres para fazer >> com que ele cancele a operação e feche a conexão normalmente, é o que o >> `pg_terminate_backend` faz (só não tenho certeza absoluta que na 8.1 já era >> assim, mas creio que sim), ou ainda, executar um `kill -SIGINT` e fazer com >> que ele só cancele a operação corrente, o que é equivalente ao >> `pg_cancel_backend`. >> >> Inclusive, você pode fazer o mesmo com o postmaster [2]. >> >> Agora, o `kill -9` (SIGKILL) não pode ser "ouvido" pelo PostgreSQL, então >> é abrupto e não dá chance do pobre elefante se proteger, podendo levar à >> problemas mais sérios (como esse). >> >> >> > > Pois é Matheus, costumamos falar que o Kill -9 é igual tiro na cabeça: > "estraga o velório". kkkk > > Tenho certeza que o adm que fez isso não vai fazer mais.. > > > >> Já que você deve ter conexões reservadas ao postgres, e o mesmo >>> consegue matar conexão por dentro do banco. >>> >>> >> Esse é um ponto muito importante. Vejo muita gente usando o superusuário >> para como usuário da aplicação, isso é COMPLETAMENTE ERRADO. Inclusive pela >> mensagem de warning do colega, parece que esse era o caso... ouch... >> >> [1] >> http://www.postgresql.org/docs/current/static/functions-admin.html#FUNCTIONS-ADMIN-SIGNAL-TABLE >> [2] http://www.postgresql.org/docs/8.1/static/postmaster-shutdown.html >> >> 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 >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
