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 sistemapg_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
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çãoCONCURRENTLY
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 umVACUUM 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 relationschema.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:
-
Reduza a taxa de transação, se possível. Considere agrupar transações semelhantes sempre que possível.
-
Defina tabelas atualizadas com frequência com a operação
VACUUM FREEZE
manual noturna, semanal ou quinzenal durante horários de baixo movimento. -
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.