Existem técnicas/ferramentas/metodologias para investigar corrupção de nível de linha em uma tabela postgres?
A maioria das soluções propostas neste fórum se resume a 'tente fazer um VACUUM FULL para reconstruir a tabela, se isso não funcionar, solte a tabela e restaure do backup'
Existe alguma maneira de realmente corrigir os dados? existe alguma maneira de ler e editar manualmente os arquivos de dados brutos do postgres e remover / reparar apenas as linhas corrompidas?
O sistema em que estou trabalhando lê dados diretamente de um feed externo para uma tabela postgres e, em seguida, mostra evidências de corrupção antes que o processo de backup noturno tenha a chance de salvá-lo. Reexecutar o feed externo não é uma opção, portanto, na prática, se houver alguma corrupção, os dados do dia inteiro serão perdidos.
Existem duas (bem, uma e um wrapper) ferramentas que podem ser incluídas no PostgreSQL que podem ajudá-lo aqui - amcheck e pg_amcheck .
amcheck:
amchecké um módulo contrib (doravante, cm) - esses são recursos adicionais fornecidos como parte da distribuição de origem, mas não ativados por padrão. Observe que muitos desses cm's são amplamente usados e também que muitos sugerem que eles devem vir por padrão - no entanto, a filosofia "lean and mean" do PostgreSQL significa que eles não são e pode levar tempo para o novo usuário descobrir exatamente como aproveitá-los ao máximo.A
pg_stat_statementsextensão, por exemplo, é amplamente utilizada e recomendada por todos os pesos-pesados da comunidade PostgreSQL. BTW, "módulo de contribuição" e "extensão" são basicamente sinônimos . Observe, no entanto, que, embora todos os cms sejam extensões, nem todas as extensões são cms - longe disso. Por exemplo, embora nem TimescaleDB nem CitusData sejam cm's (ou seja, eles não são empacotados com o código-fonte), eles são extensões! Existe todo um ecossistema de extensão do PostgreSQL por aí, caso você esteja interessado.Perdoe o desvio, de volta ao ponto em questão!
No PostgreSQL, uma relação é uma tabela ou um índice.
Você pode visitar a página amcheck para obter mais detalhes sobre sua funcionalidade.
pg_amcheck:
O utilitário pg_amcheck pode ser encontrado no
$PGHOME/bindiretório. Ele só será encontrado lá se o banco de dados for compilado usandomake worldou equivalente. Ele pode ou não ser instalado em sua própria distribuição dependendo - posso confirmar que está incluído na distribuição Windows (14) do EnterpriseDB - não posso falar com outras distribuições no momento.Como mencionado acima, é um wrapper em torno da
amcheckextensão:A extensão amcheck deve ser instalada para poder usar o wrapper (faz sentido!).
Observe (da página):
Em geral, o amcheck só pode comprovar a presença de corrupção; não pode provar sua ausência.
(parafraseando) - amcheck só funciona em índices de árvore B.
Este último é, (IMHO), uma lacuna grosseira.
Caso de uso:
Então, vamos dar uma olhada em um caso de uso prático para essas ferramentas.
Em 24/05/2022, Michael Paquier twittou sobre um problema com potencial corrupção usando o PostgreSQL 14
Em 2022-06-02 Um artigo no pganalyze.com mostra como usar o amcheck para confirmar o bug e ver se ele afetou seus sistemas
Resumo:
O ponto aqui é - eu acho - que nenhum sistema [é | pode ser | sempre será] perfeito e que ferramentas como essas [são | pode ser | pode ser] necessário de vez em quando nos casos em que pode haver problemas em potencial - é um pouco como o direito de autodefesa - você nunca quer ter que usá-lo, mas sabe que está lá caso o faça!
NB PostgreSQL desde então fez um lançamento fora do ciclo em 2022-06-09 - o melhor de tudo isso é que tudo foi feito abertamente, em listas de discussão, para todos verem!