Como posso solucionar problemas de armazenamento local em instâncias do Aurora compatível com PostgreSQL?

Breve descrição

As instâncias de banco de dados que estão nos clusters do Amazon Aurora têm dois tipos de armazenamento:

• Armazenamento usado para dados persistentes (volume de cluster compartilhado). Para obter mais informações, consulte O que o volume do cluster contém.
• Armazenamento local para cada instância do Aurora no cluster, com base na classe da instância. Esse tamanho de armazenamento está vinculado à classe da instância e só pode ser alterado com a migração para uma classe de instância de banco de dados maior. Aurora compatível com PostgreSQL usa armazenamento local para armazenar logs de erros e arquivos temporários. Para obter mais informações, consulte Limites temporários de armazenamento do Aurora PostgreSQL.

Resolução

Você pode monitorar o espaço de armazenamento local associado ao nó ou à instância de banco de dados Aurora usando a métrica do Amazon CloudWatch para FreeLocalStorage. Essa métrica relata a quantidade de armazenamento disponível para cada instância de banco de dados para tabelas e logs temporários. Para obter mais informações, consulte Monitoramento de métricas do Amazon Aurora com o Amazon CloudWatch.

Se o armazenamento local do Aurora estiver cheio, use essas etapas de solução de problemas, dependendo do erro que você receber.

O espaço de armazenamento local é usado por tabelas ou arquivos temporários

“ERRO: não foi possível gravar o bloco XXXXXXXX do arquivo temporário: não há mais espaço no dispositivo.”

Esse erro ocorre quando o armazenamento temporário está esgotado na instância de banco de dados. Isso pode ter várias causas, incluindo operações que:

• Alteram tabelas grandes
• Adicionam índices em tabelas grandes
• Executam grandes consultas SELECT com cláusulas JOINs, GROUP BY ou ORDER BY complexas.

Use esses métodos para verificar o tamanho das tabelas temporárias e dos arquivos temporários:

1.    Para arquivos temporários, ative o parâmetro log_temp_files na instância de banco de dados compatível com o Aurora PostgreSQL. Esse parâmetro registra o uso de arquivos temporários maiores que o número de kilobytes especificados. Depois que esse parâmetro é ativado, uma entrada de log é feita para cada arquivo temporário quando o arquivo é excluído. Um valor de 0 registra todas as informações do arquivo temporário. Um valor positivo registra somente os arquivos maiores ou iguais ao número especificado de kilobytes. O valor padrão é -1, o que desativa o registro em log temporário de arquivos. Use esse parâmetro para identificar os detalhes do arquivo temporário e relacionar esses arquivos temporários com a métrica FreeLocalStorage.

Observação: ativar o parâmetro log_temp_files pode causar um registro em log excessivo na instância de banco de dados compatível com o Aurora PostgreSQL. Por esse motivo, é uma prática recomendada verificar o tamanho dos arquivos de log compatíveis com o Aurora PostgreSQL antes de ativar log_temp_files. Se os arquivos de log estiverem consumindo o máximo de espaço do armazenamento local, reduza o valor de rds.log_retention para recuperar espaço. O valor padrão para rds.log_retention é de três dias.

Você também pode revisar arquivos temporários usando o delta das execuções subsequentes desse comando:

maxiops=> select datname, temp_files , pg_size_pretty(temp_bytes) as temp_file_size  FROM   pg_stat_database order by temp_bytes desc;

Observação: na coluna temp_files, todos os arquivos temporários são contados, independentemente de quando você criou o arquivo temporário (por exemplo, por classificação ou hash). A colunas temp_files e temp_bytes na exibição pg_stat_database estão coletando estatísticas do valor acumulado. Esse valor pode ser redefinido usando a função pg_stat_reset() ou reiniciando a instância de banco de dados. Para obter mais informações, consulte a documentação do PostgreSQL para ver Funções estatísticas adicionais.

Se você usa o Aurora compatível com PostgreSQL10 ou superior, poderá monitorar temp_bytes e temp_files usando o Performance Insights. Isso também se aplica ao Amazon Relational Database Service (Amazon RDS) para o PostgreSQL. O Performance Insights fornece contadores nativos para as métricas internas do seu mecanismo de banco de dados, além de eventos de espera. Para obter mais informações, consulte Contadores nativos do Amazon RDS para PostgreSQL.

Você também pode aumentar maintenance_work_mem e work_mem para alocar mais memória aos processos que estão executando a operação. Isso usa mais memória para a operação, podendo demandar menos armazenamento temporário em disco. Para obter mais informações sobre esses parâmetros, consulte a documentação do PostgreSQL para maintenance_work_mem e work_mem. É uma prática recomendada definir os valores para maintenance_work_mem e work_mem em nível de consulta ou sessão para evitar falta de memória. Para obter mais informações, consulte a referência do Amazon Aurora PostgreSQL.

2.    Para tabelas temporárias, execute uma consulta como esta:

maxiops=> SELECT
n.nspname as SchemaName
,c.relname as RelationName
,CASE c.relkind
WHEN 'r' THEN 'table'
WHEN 'v' THEN 'view'
WHEN 'i' THEN 'index'
WHEN 'S' THEN 'sequence'
WHEN 's' THEN 'special'
END as RelationType
,pg_catalog.pg_get_userbyid(c.relowner) as RelationOwner
,pg_size_pretty(pg_relation_size(n.nspname ||'.'|| c.relname)) as RelationSize
FROM pg_catalog.pg_class c
LEFT JOIN pg_catalog.pg_namespace n
    ON n.oid = c.relnamespace
WHERE  c.relkind IN ('r','s')
AND  (n.nspname !~ '^pg_toast' and nspname like 'pg_temp%')
ORDER BY pg_relation_size(n.nspname ||'.'|| c.relname) DESC;

É uma prática recomendada monitorar de perto sua aplicações e ver quais transações criam tabelas temporárias. Ao fazer isso, você pode gerenciar o uso da capacidade de armazenamento local disponível. Você também pode migrar para uma classe de instância superior para sua instância do Aurora para que a instância tenha mais armazenamento local disponível.

Armazenamento local usado pelos arquivos de log

O registro em log excessivo também pode fazer com que sua instância de banco de dados fique sem armazenamento local. Esses são alguns exemplos de parâmetros de registro em log que podem consumir o espaço de armazenamento local. O consumo pode ser devido ao registro em log excessivo ou à retenção do log de erros por um longo período.

rds.log_retention_period
auto_explain.log_min_duration
log_connections
log_disconnections
log_lock_waits
log_min_duration_statement
log_statement
log_statement_stats

Para identificar qual parâmetro está causando o registro em log excessivo, analise os logs do PostgreSQL para encontrar os maiores registros. Em seguida, identifique qual parâmetro é responsável pela maioria das entradas nesses logs. Agora você pode modificar o parâmetro que está causando o registro em log excessivo.

Se você estiver executando repetidamente uma consulta que está falhando com um erro, o PostgreSQL registra em log os erros no log de erros do PostgreSQL por padrão. Analise os erros registrados em log e, em seguida, corrija a falha na consulta para evitar que os logs usem armazenamento excessivo. Você também pode reduzir o valor padrão de rds.log_retention (três dias) para recuperar o espaço usado pelos logs de erros.

Se for necessário um registro em log excessivo e você estiver controlando o armazenamento local disponível devido aos arquivos de log, considere migrar para uma classe de instância superior. Isso significa que sua instância de banco de dados do Aurora tem mais armazenamento local disponível.

---

Informações relacionadas

Melhores práticas com o Amazon Aurora PostgreSQL