Início / dba / Perguntas / 314079
Accepted
awestover89
Asked: 2022-07-06 04:47:26 +0800 CST

Postgres: Como descobrir de onde vem o crescimento do tamanho do banco de dados

  • 772

Temos um banco de dados PostgreSQL que cresceu significativamente em tamanho recentemente, de cerca de 340 GB para 571 GB nos últimos dois meses, e não estamos rastreando nenhuma mudança significativa no comportamento do usuário durante esse período. Nosso principal DBA fez algumas recomendações, sendo sua principal recomendação exportar todo o banco de dados e reimportá-lo, o que de seus testes em um segundo servidor clonado de nosso primário requer cerca de 3 horas de inatividade e obtém o tamanho para apenas 300 GB.

Minhas duas principais áreas de preocupação seriam descobrir de onde vem esse crescimento significativo (usando du -h, posso pelo menos ver que está no diretório /data sem crescimento significativo no tablespace ou pg_wal) e entender como importar e exportar o banco de dados pode nos fornecer quase 300 GB de recuperação de espaço sem realmente perder nenhum dado de produção.

postgresql postgresql-12

2 respostas

  1. A primeira coisa que eu faria é mudar para o diretório de dados e executar

    du -sk *

    Isso mostrará em qual dos subdiretórios é usado muito espaço em disco. Você pode detalhar descendo mais fundo e repetindo o comando.

    Normalmente, o aumento no uso do disco vem de uma das duas causas:

    1. WAL in pg_walnão pode ser removido. Isso pode ocorrer porque o arquivador tem um problema (veja pg_stat_archiver) ou você tem um slot de replicação obsoleto (veja pg_replication_slots).

    2. Algumas tabelas ou índices estão inchados.

      Se você criou uma cópia do banco de dados com pg_dump/restore, está na metade do caminho para a solução. Execute algo assim nos dois bancos de dados:

      SELECT oid::regclass AS object, relkind, pg_relation_size(oid) AS size
FROM pg_class
ORDER BY size DESC;

      Compare a saída em ambos os lados e observe tabelas e índices que são consideravelmente maiores no banco de dados original.

      Corrija o inchaço examinando as possíveis causas . Feito isso, livre-se do bload com VACUUM (FULL)(atenção, isso requer tempo de inatividade).

    • 1
  2. Best Answer

    Por fim, usamos o seguinte para determinar o problema:

    Fizemos uma exportação e importação para um servidor de banco de dados de teste para que tivéssemos uma cópia do banco de dados em tamanho real e uma cópia do banco de dados no tamanho menor, pós-importação.

    Em seguida, executamos a seguinte consulta para identificar as maiores tabelas:

    SELECT schema_name as table_schema, relname as table_name, pg_size_pretty(pg_relation_size(relid)) as data_size FROM pg_catalog.pg_stat_all_tables ORDER BY pg_relation_size(relid) DESC;

    Isso mostrou claramente que no sistema principal a tabela pg_catalog.pg_largeobject tinha pouco mais de 200 GB enquanto no sistema de teste após a exportação e importação tinha 0 bytes.

    Estamos agora trabalhando em um plano para gerenciar melhor o crescimento do pg_largeobject.

    • 0

relate perguntas