“postgres bloqueados por mais de 120 segundos” - o meu banco de dados ainda é consistente?

Question

Estou usando um volume iscsi em um sistema de armazenamento Open-E para várias máquinas virtuais em execução em um host XenServer. Ocasionalmente, quando há uma carga de E / S de disco muito alta nas máquinas virtuais (e, portanto, também no sistema de armazenamento), recebi essa mensagem de erro nos consoles da VM:

[2594520.161701] INFO: task kjournald:117 blocked for more than 120 seconds.
[2594520.161787] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[2594520.162194] INFO: task flush-202:0:229 blocked for more than 120 seconds.
[2594520.162274] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[2594520.162801] INFO: task postgres:1567 blocked for more than 120 seconds.
[2594520.162882] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Eu entendo que esta mensagem de erro é causada pelo kernel para informar que estes processos não foram executados por 120 segundos, muito provavelmente porque um acesso ao disco para o sistema de armazenamento ainda não foi processado.

Mas qual é o efeito nos processos. Por exemplo, o processo postgres eventualmente gravará seus dados quando o sistema de armazenamento estiver ocioso novamente após alguns minutos, para que todos os dados ainda sejam consistentes? Ou abortará a gravação, deixando algumas tabelas em um estado inconsistente?

Eu certamente espero que o primeiro seja o caso - se o acesso ao disco for lento, postgres (ou qualquer outro processo afetado) deve esperar o tempo que for necessário. Eu posso viver com o aplicativo pendurado por alguns minutos. Mas se houver uma chance de corrupção de dados, qualquer um desses erros é uma má notícia.

Por favor, informe o que fazer aqui.

    

Answer 1

Sua intuição de que o banco de dados permaneceria consistente deveria estar correta, a menos que o motivo dos interrupções de 120 segundos seja o próprio disco falhando. Se a causa raiz é realmente apenas alta E / S, o PostgreSQL irá garantir que a ordem que ele envia dados para o disco irá garantir que ele não esteja corrompido.

Já tive situações em que os discos SATA com falha tendem a ficar suspensos, esperando que as operações de E / S sejam concluídas e resultem nesse erro do kernel. No momento em que isso acontece, você provavelmente não pode confiar muito nos dados desse disco - o atraso de 120 segundos é apenas um efeito colateral, e não a causa raiz da corrupção.

    

Answer 2

Se você estiver usando transações, estará seguro, pois pode ter certeza de que os dados persistirão quando a transação for concluída (a transação é uma operação de tudo ou nada). Se você não estiver usando transações, alguns dados poderão ser perdidos ou parcialmente atualizados, etc. Mais informações sobre transações

    

Answer 3

Se você estiver preocupado com a consistência, considere o uso de uma ferramenta como diskchecker.pl para garantir que seu disco esteja honrando os flushes. Você também pode usar pg_test_fsync e ver se está recebendo taxas suspeitas de alta fsync () que podem indicar o cache de gravação inseguro, a menos que você saiba que tem um cache de write-back super rápido e seguro contra falhas.

Veja a documentação do PostgreSQL sobre confiabilidade de gravação para obter informações sobre essas ferramentas e outras opções .

As propriedades que seu armazenamento deve ter para ser confiável são:

• Quando uma gravação for liberada com fsync() , gravar barreiras, O_SYNC ou similar, ela deverá estar em um armazenamento durável que não esteja limpo ou corrompido em perda de energia, falha do sistema operacional, VM guest ou falha do host , etc.

• A solicitação de fsync() solicitações deve ser honrada, para que, se as confirmações A , B e C ocorrerem na ordem escrita, seus dados também sejam liberados para armazenamento durável nessa ordem . Não é permitido ao sistema otimizar as coisas misturando as gravações de C e B nas gravações de A para melhor desempenho, pois se ele falhar / perder energia na metade do caminho, você terá dados gravados fora de ordem e replay WAL não será confiável.

• Quando um bloco tiver sido liberado com fsync() , ele deverá ser recuperável do armazenamento. O armazenamento ou armazenamento somente de gravação que retorna um valor diferente do que você forneceu não é muito bom.

Se o seu armazenamento tiver essas duas propriedades, não importa se ele trava, reordena as gravações (contanto que não o faça através de barreiras / sincronizações), os caches gravam (desde que honre o cache flushes), etc.

É difícil superar o teste plug-pull. Isso é exatamente o que diz. Durante os testes de aprovação / pré-implantação, arranque a energia de todo o sistema enquanto ele estiver sob carga, inicialize-o novamente e verifique se o DB repete seus logs e se recupera de forma limpa. Repita.