On 09/26/2013 07:57 PM, Matheus de Oliveira wrote:
2013/9/26 Adriano Espinoza de Oliveira <adrianoespin...@gmail.com
<mailto:adrianoespin...@gmail.com>>
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]: [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.
*
*
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`.
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
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".
[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 <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
