Fala, galera!
Hoje vamos falar de PostgreSQL. Se você já utilizou este S.G.B.D, é muito provável que já tenha ouvido falar sobre o Autovacuum.
Mas, você sabe o que ele faz e porque ele é tão importante para a manutenção de espaço em disco, performance e até integridade do seu banco de dados?
Ao final deste post você terá uma melhor compreesão de:
- O que é o Autovacuum;
- Por que ele é essencial;
- O que ele tem a ver com comandos como VACUUM FULL, ANALYZE e REINDEX;
E ainda vamos falar de uma ferramenta muito útil chamada pg_repack.
M.V.C.C.
Para entender o que é o Autovacuum, é importante entendermos como o PostgreSQL funciona quanto às atualizações de uma tabela em um banco de dados.
O PostgreSQL utiliza o sistema M.V.C.C. — Multi-Version Concurrency Control.
Isso, basicamente, significa que quando um registro é atualizado, este sistema, em vez de realmente atualizar o registro, gera uma nova versão da linha, e mantém a versão antiga.
Chamamos estas versões antigas de registros de tuplas mortas.
Com o passar do tempo, e o aumento do número de tuplas mortas, as tabelas ficam maiores, os índices ficam menos eficientes, e o desempenho do banco de dados piora.
E é aqui que o Autovacuum torna-se essencial.
Agora, sim – o que é o Autovacuum?
O Autovacuum é uma propriedade do banco de dados PostgreSQL que, para funcionar corretamente, precisa estar habilitada para realizar seu trabalho.
Basicamente, o Autovacuum executa automaticamente duas ações em segundo plano.
- VACUUM – Marca as tuplas mortas como reutilizáveis, liberando espaço interno para novas atualizações.
- ANALYZE – Atualiza estatísticas para ajudar o otimizador a planejar melhor as queries.
Essas ações são leves, não causam bloqueios e não precisam ser agendadas. Mas, precisam ser configuradas.
Como configurar o Autovacuum?
Você pode fazer as principais configurações por meio dos seguintes parâmetros, que permitem ajustar o comportamento do sistema conforme sua necessidade:
- autovacuum_vacuum_threshold: número mínimo de tuplas mortas para acionar o vacuum.
- autovacuum_vacuum_scale_factor: percentual da tabela que, se tiver tuplas modificadas, dispara o vacuum.
- autovacuum_analyze_threshold e autovacuum_analyze_scale_factor: funcionam da mesma forma, mas para o ANALYZE.
Exemplo: Quando uma tabela tem 1 milhão de linhas e o scale_factor é 0,2 (20%), o Autovacuum aciona após a modificação de 200.000 linhas.
Existem diversas outras configurações que você precisa estudar para configurar de forma adequada em cada ambiente.
E se eu não quiser habilitar o Autovacuum?
Não habilitar o Autovacuum é possível, mas só recomendamos se você tiver muito conhecimento e controle do seu ambiente, porque, se o Autovacuum estiver desabilitado:
- Seu banco de dados crescerá sem controle;
- A performance das consultas naturalmente cairá;
- E o pior: você pode sofrer com wraparound.
Pera aí! O que é esse wraparound?
Para que o MVCC consiga controlar quais são as versões antigas e qual é a versão atualizada de um registro, os registros recebem números chamados Transaction ID’s, ou simplesmente XID’s. Esses XID’s têm um limite: pouco mais de 4 bilhões. Quando esse limite é atingido, ele zera e inicia uma nova contagem. Aí o PostgreSQL perderá controle dos que são XID’s passados, XID’s futuros, dados antigos e dados atuais. Uma parada do banco e até corrupção de dados torna-se iminente.
Para evitar que isso aconteça, o PostgreSQL dispara um Autovacuum, o qual será executado até que ele entenda que o número de XID’s está novamente sob controle. Aliás, quem sabe não exploramos melhor esse conceito em outro post?!
Comparando VACUUM, VACUUM FULL, ANALYZE e REINDEX
*E o pg_repack?
Se você precisa reduzir o tamanho das tabelas sem bloquear o banco, uma alternativa interessante é usar o pg_repack, uma extensão do PostgreSQL.
Basicamente, o pg_repack funciona recriando tabelas e índices como objetos temporários, sem a necessidade de parar o banco. Então, quando concluir a criação, substituíra os objetos envolvidos. Nesse momento, ocorre um rápido bloqueio durante a substituição dos objetos.
- Ele mantém seu banco limpo e eficiente;
- Ele protege contra o temido wraparound;
- Ele atua em segundo plano;
- Você deve personalizar conforme o seu ambiente.
Se precisar reorganizar tabelas e/ou índices sem parar o banco, então considere usar o pg_repack como complemento às estratégias de manutenção.
Espero ter esclarecido um pouco desse parâmetro, que é fundamental para a manutenção do seu banco de dados.
Até a próxima!
Por Jonas Natario
