Solucionar bloqueadores de limpeza não identificáveis no RDS para PostgreSQL - Amazon Relational Database Service

Solucionar bloqueadores de limpeza não identificáveis no RDS para PostgreSQL

Esta seção explora razões adicionais que podem impedir o progresso da limpeza. Esses problemas atualmente não são diretamente identificáveis pela função postgres_get_av_diag().

Páginas inválidas

Um erro de página inválida ocorre quando o PostgreSQL detecta uma incompatibilidade na soma de verificação de uma página ao acessá-la. O conteúdo é ilegível, impedindo que o autovacuum congele as tuplas. Isso efetivamente interrompe o processo de limpeza. O seguinte erro é registrado no log do PostgreSQL:

WARNING: page verification failed, calculated checksum YYYYY but expected XXXX ERROR: invalid page in block ZZZZZ of relation base/XXXXX/XXXXX CONTEXT: automatic vacuum of table myschema.mytable

Determinar o tipo de objeto

ERROR: invalid page in block 4305910 of relation base/16403/186752608 WARNING: page verification failed, calculated checksum 50065 but expected 60033

A partir da mensagem de erro, o caminho base/16403/186752608 fornece as seguintes informações:

  • "base" é o nome do diretório sob o diretório de dados do PostgreSQL.

  • "16403" é o OID do banco de dados, que você pode consultar no catálogo do sistema pg_database.

  • "186752608" é o relfilenode, que você pode usar para pesquisar o esquema e o nome do objeto no catálogo do sistema pg_class.

Ao verificar a saída da consulta a seguir no banco de dados afetado, será possível determinar o tipo de objeto. A consulta a seguir recupera informações do objeto para oid: 186752608. Substitua o OID pelo relevante para o erro que você encontrou.

SELECT relname AS object_name, relkind AS object_type, nspname AS schema_name FROM pg_class c JOIN pg_namespace n ON c.relnamespace = n.oid WHERE c.oid = 186752608;

Para obter mais informações, consulte a documentação do PostgreSQL pg_class para ver todos os tipos de objetos compatíveis, indicados pela coluna relkind em pg_class.

Orientação

A solução mais eficaz para esse problema depende da configuração da instância específica do Amazon RDS e do tipo de dados afetados pela página inconsistente.

Se o tipo de objeto for um índice:

É recomendável reconstruir o índice.

  • Usar a opção CONCURRENTLY: antes da versão 12 do PostgreSQL, a reconstrução de um índice exigia um bloqueio de tabela exclusivo, restringindo o acesso à tabela. Com a versão 12 e posteriores do PostgreSQL, a opção CONCURRENTLY permite o bloqueio em nível de linha, melhorando significativamente a disponibilidade da tabela. Este é o comando:

    REINDEX INDEX ix_name CONCURRENTLY;

    Embora CONCURRENTLY seja menos disruptivo, pode ser mais lento em tabelas acessadas com frequência. Considere construir o índice durante períodos de baixo tráfego, se possível.

    Para obter mais informações, consulte a documentação REINDEX do PostgreSQL.

  • Usar a opção INDEX_CLEANUP FALSE: se os índices forem grandes e, segundo sua avaliação, exigirem muito tempo para serem concluídos, é possível desbloquear o autovacuum executando um VACUUM FREEZE manual ao excluir os índices. Essa funcionalidade está disponível na versão 12 e versões posteriores do PostgreSQL.

    Ignorar os índices permitirá que você pule o processo de limpeza do índice inconsistente e mitigue o problema de conclusão. No entanto, isso não resolverá o problema subjacente da página inválida. Para abordar e resolver totalmente o problema da página inválida, ainda será necessário reconstruir o índice.

Se o tipo de objeto for uma visão materializada:

Se ocorrer um erro de página inválida em uma visão materializada, faça login no banco de dados afetado e atualize-a para resolver a página inválida:

Atualize a visão materializada.

REFRESH MATERIALIZED VIEW schema_name.materialized_view_name;

Se a atualização falhar, tente recriar:

DROP MATERIALIZED VIEW schema_name.materialized_view_name; CREATE MATERIALIZED VIEW schema_name.materialized_view_name AS query;

Atualizar ou recriar a visão materializada a restaura sem afetar os dados da tabela subjacente.

Para todos os outros tipos de objetos:

Para todos os outros tipos de objetos, entre em contato com o AWS Support.

Inconsistência do índice

Um índice logicamente inconsistente pode impedir que o autovacuum progrida. Os seguintes erros ou erros semelhantes são registrados em log durante a fase de limpeza do índice ou quando o índice é acessado por instruções SQL.

ERROR: right sibling's left-link doesn't match:block 5 links to 10 instead of expected 2 in index ix_name
ERROR: failed to re-find parent key in index "XXXXXXXXXX" for deletion target page XXX CONTEXT: while vacuuming index index_name of relation schema.table

Orientação

Reconstrua o índice ou pule índices usando INDEX_CLEANUP no manual VACUUM FREEZE. Para obter informações sobre como reconstruir o índice, consulte Se o tipo de objeto for um índice.

  • Usar a opção CONCURRENTLY: antes da versão 12 do PostgreSQL, a reconstrução de um índice exigia um bloqueio de tabela exclusivo, restringindo o acesso à tabela. Com a versão 12 e posteriores do PostgreSQL, a opção CONCURRENTLY permite o bloqueio em nível de linha, melhorando significativamente a disponibilidade da tabela. Este é o comando:

    REINDEX INDEX ix_name CONCURRENTLY;

    Embora CONCURRENTLY seja menos disruptivo, pode ser mais lento em tabelas acessadas com frequência. Considere construir o índice durante períodos de baixo tráfego, se possível. Para ter mais informações, consulte a documentação REINDEX do PostgreSQL.

  • Usar a opção INDEX_CLEANUP FALSE: se os índices forem grandes e, segundo sua avaliação, exigirem muito tempo para serem concluídos, é possível desbloquear o autovacuum executando um VACUUM FREEZE manual ao excluir os índices. Essa funcionalidade está disponível na versão 12 e versões posteriores do PostgreSQL.

    Ignorar os índices permitirá que você pule o processo de limpeza do índice inconsistente e mitigue o problema de conclusão. No entanto, isso não resolverá o problema subjacente da página inválida. Para abordar e resolver totalmente o problema da página inválida, ainda será necessário reconstruir o índice.

Taxa de transação excepcionalmente alta

No PostgreSQL, altas taxas de transação podem afetar significativamente o desempenho do autovacuum, levando a uma limpeza mais lenta das tuplas inativas e ao aumento do risco de conclusão do ID da transação. É possível monitorar a taxa de transação medindo a diferença em max(age(datfrozenxid)) entre dois períodos, normalmente por segundo. Além disso, é possível usar as métricas de contador do Insights de Performance do RDS a seguir para medir a taxa de transação (a soma de xact_commit e xact_rollback), que é o número total de transações.

Contador Type Unidade Métrica

xact_commit

Transações

Confirmações por segundo

db.Transactions.xact_commit

xact_rollback

Transações

Reversões por segundo

db.Transactions.xact_rollback

Um aumento rápido indica uma alta carga de transações, que pode sobrecarregar o autovacuum, causando sobrecarga, contenção de bloqueios e possíveis problemas de desempenho. Isso pode impactar negativamente o processo de autovacuum de duas maneiras:

  • Atividade da tabela: a tabela específica que está sendo limpa pode estar passando por um alto volume de transações, causando atrasos.

  • Recursos do sistema: o sistema geral pode estar sobrecarregado, dificultando que o autovacuum acesse os recursos necessários para funcionar com eficiência.

Considere as seguintes estratégias para permitir que o autovacuum opere com mais eficiência e acompanhe suas tarefas:

  1. Reduza a taxa de transação, se possível. Considere agrupar transações semelhantes sempre que possível.

  2. Defina tabelas atualizadas com frequência com a operação VACUUM FREEZE manual noturna, semanal ou quinzenal durante horários de baixo movimento.

  3. Considere aumentar a escala verticalmente da classe de instância para alocar mais recursos do sistema para lidar com o alto volume de transações e o autovacuum.