Solucionar bloqueadores de limpeza não identificáveis no Aurora PostgreSQL - Amazon Aurora

Solucionar bloqueadores de limpeza não identificáveis no Aurora 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().

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.

  • 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.