Em 26 de setembro de 2013 19:57, Matheus de Oliveira < [email protected]> escreveu:
> > > > 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... >> >> > Derrubou como? Se foi um "kill -9" é bom dar um "kill -9 `pidof > cara_que_fez_isso`"... =P > Pois é, ele já está segurando o próprio anus... > > > 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 >> * >> *(...)* >> >> > 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]: [7-1] >> db=nutracom,user=postgres WARNING: could not remove relation >> 1663/105809227/572937590: Arquivo ou diretório não encontrado >> 10.35.0.2 2013-09-26 18:01:28 BRT [16124]: [8-1] >> db=nutracom,user=postgres WARNING: could not remove relation >> 1663/105809227/572937597: Arquivo ou diretório não encontrado >> >> * >> > > Ok. Parece que ou seu reindex não foi realmente em todos os índices ou há > alguma heap corrompida. > Eu realmente não reindexei todas as bases, deixei duas de fora, pois não encontrei o erro no log citando elas. > > * >> * >> Não estou certo de como proceder: dump/ restore do banco, drop/create dos >> indices, ou alguma outra tentativa: >> >> > Primeiro. Você tem certeza que reindexou tudo? Incluíndo tabelas de > sistema? Tente um `REINDEX SYSTEM`. > Não reindexei as tabelas de sistemas tb. > > Pelo erro que apresentou em outra mensagem parece ter sido índices de > tabelas de sistema com erro: > > > 2013-09-26 18:37:50 BRT [19470]: [2-1] db=,user= PANIC: right > sibling is not next child in "pg_class_relname_nsp_index" > > Agora, mesmo que a reindexação das tabelas de sistema resolva o problema, > eu faria, por segurança, o seguinte procedimento: > > 1. Bloquear toda e qualquer conexões de usuários/aplicações; > 2. Executar um dump de todas as bases; > 3. Apagar TUDO (faça um backup antes, claro); > 4. Executar o initdb novamente e ter uma instância novinha em folha; > 5. Executar um restore; > 6. Dormir mais tranquilo... =D > Acho que essa é a melhor opção, nova instância e pronto. Meu medo maior era ter problema no dump/restore, mas acho q não deve ser o problema não é? De qq forma vou criar uma nova instancia e deixar a antiga parada, mas seguro né? só vou ver a questão de espaço em disco > > >> Servidor Linux, Postgresql 8.1.18, esse é o servidor de produção que >> está estável, com espaço em disco e memória sobrando. >> Tenho uma unica instancia do postgres com vários databases. >> >> > > Bom. Não vou repetir o DUTRA e dizer que sua versão já não tem mais > suporte, o risco é seu... MAS... Veja que na versão 8.1 a mais estável é a > 8.1*.23*, e você está na 8.1*.18*, cinco versões atrasadas, logo atualize > IMEDIATAMENTE para a versão 8.1*.23*, como já discutido infinitas vezes > nessa lista uma atualização de release (o último número só) NÃO CAUSA > INCOMPATIBILIDADE com a aplicação, basta atualizar os binários, mais nada... > > Ah, veja também os release notes da 8.1.23 e vá seguindo o texto em > "Migrating to version XXXX", pode ser que você esteja enfrentando um bug > conhecido e corrigido nas versões mais recentes. Por exemplo, na 8.1.18 > houve uma correção em índices em colunas "interval", e na 8.1.15 com > índices GiST, já na 8.1.2 com índices "text". > Sem duvida, vou fazer isso, e na sequencia migrar para no minimo o 8.4. Por enquanto muito obrigado. > > [1] http://www.postgresql.org/docs/8.1/static/release.html#RELEASE-8-1-23 > > 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
