Todo DBA um dia vai se deparar com esta situação. Um colega na lista chegou nesta situação e perguntou o que fazer.
Antes de comprar um novo disco:
Vejamos o que podemos fazer antes de sair correndo para colocar um novo disco.
VACUUM
Antes de mais nada, você deve rodar um VACUUM FULL no se banco de dados para reclamar o espaço em disco desperdiçado. Rodar um VACUUM deve ser rotina no PostgreSQL, se você não o faz… terá uma boa surpresa quando finalmente o rodar.
WAL
De qualquer forma, se você já sabe que o espaço ocupado pelo PostgreSQL já está bem comportado, está na ora de olhar para outros possível comedores de espaço em disco: os logs! Se você está num ambiente de produção, você deveria estar arquivando os logs do WAL em algum lugar. Se você tem o hábito de fazer backup físico on-line, faça um off-line e guarde todos os seus logs arquivados em fita. O backup off-line permite que você não precise de nenhum log arquivado com data anterior ao backup para restaurar o banco. Outros logs, como logs do PostgreSQL também podem ocupar muito espaço. Vale a pena guardar os mais antigos em outro lugar. Para saber onde ficam os seus logs, verifique a configuração do seu arquivo ‘postgresql.conf’.
Tabelas de Histórico
Este é o limite da economia que você pode chegar. Procure por tabelas que guarde informações de auditoria ou dados históricos não utilizados e faça um backup destes dados. Depois simplesmente exclua os registros. Particionar este tipo de tabela costuma ser uma boa idéia, uma vez que lhe permite agilizar o processo de apagar registros antigos utilizando o TRUNCATE na partição da tabela. Também fica mais simples fazer o bakcup antes de apagar os registros.
Adicionando um novo disco:
Bom, você fez o possível para economizar alguns gigabytes enquanto o seu disco novo não chegava, mas chegou a hora acrescentar um novo disco. Nunca espere seus discos chegarem a mais de 80% de capacidade de armazenamento para adicionar um novo disco. Faça o possível e o impossível para acrescentar o novo disco ANTES de acabar o espaço com uma margem se segurança de 20%. Outra coisa importante é acompanhar o crescimento da base, saber qual é a taxa de crescimento esperada e real ano a ano é fundamental para permitir um planejamento seguro para aquisição de novos discos. Enquanto um novo disco SCSI comum pode custar pouco (cerca de uns R$2000), montar um novo RAID com discos de 15Krpm num Storage Fiber Channel pode custar 100 vezes mais que isso. De qualquer forma, uma vez que o disco foi instalado fisicamente (discos Hot Swap são uma benção nestas horas) e lógicamente (com o suas partições de sistemas de arquivos), chega a hora de você alocar os seus dados. Se você adicionou um novo disco em um RAID ou LVM, tudo será transparente para o seu banco de dados e surgirá mais espaço em disco livre pronto para ser utilizado. No entanto, se você estiver realmente criando novas partições, você pode simplesmente passar a alocar novos objetos em novos Tablespaces criados nas novas partições. Se você está pretendendo colocar um novo sistema no mesmo banco de dados, esta é uma opção viável. Para sistemas já existentes, isto não funcionará, pois as tabelas e índices já se encontram alocados em um Tablespace existente.
Este é um momento oportuno para uma redistribuição dos Tablespaces entre os discos. Uma boa distribuição dos Tablespaces através dos discos deve simplificar o gerenciamento do espaço livre. Ao mesmo tempo, deve paralelizar ao máximo o uso dos discos, aumentando a velocidade geral no acesso. Existem duas formas básicas de mover dados para uma nova partição, pelo SO ou pelo PostgreSQL. Seja qual for a sua abordagem, lembre-se de antes de iniciar o seu procedimento desconectar todos os seus usuários do PostgreSQL e tirar uma cópia de segurança. Você pode desconectar seus usuários simplesmente desligando o cabo de rede do servidor. Eu realmente não recomendo isso, além de ser perigoso (no caso de uma fibra ótica, nunca faça isso) trabalhar na temperatura do ar condicionado do CPD não é tão agradável. Faça um bem para si mesmo, crie um novo arquivo pg_hba.conf que só permita conexões locais e faça a recarga (um ‘reload’) dos arquivos de configuração do PostgreSQL utilizando este arquivo.
Movendo Tablespaces via Sistema Oparacional:
- Crie as partições no novo disco;
- Desconecte todos os usuários (alterando o pg_hba.conf por exemplo);
- Faça um backup completo de toda a base;
- Baixe o PostgreSQL;
- Monte a nova partição do novo disco para um ponto de montagem provisório;
- Copie o Tablespace a ser movido para a nova partição (tenha certeza de que o PostgreSQL não está rodando antes)
- Apague todo o conteúdo na pasta original do Tablespace (certifique-se que a cópia foi realizada com sucesso e que o backup também foi realizado antes);
- Desmonte a partição nova do ponto provisório e monte no lugar do Tablespace correto. Em *nix isso é muito simples, no Windows também é possível mas é um pouco menos transparente;
- Suba novamente o PostgreSQL;
- Teste os dados no novo Tablespace;
- Restaure o acesso aos usuários;
É claro que você precisará de um pouco de conhecimento sobre sistemas de arquivos para ter sucesso. É função de todo DBA conhecer este lado do SO.Este procedimento, apesar de parecer complexo, é bastante rápido. Se você tem Tablespace já segmentadas por sistema ou tipo de carga será mais fácil utilizar este tipo de abordagem. Se você utiliza apenas os Tablespaces padrões do PostgreSQL, será necessário utilizar o procedimento a seguir.
Movendo tabelas e índices entre Tablespaces via PostgreSQL:
- Crie as partições no novo disco;
- Monte as novas partições em pontos de montagem adequados para
receber os novos Tablespaces; - Desconecte todos os usuários (alterando o pg_hba.conf por exemplo);
- Faça um backup completo de toda a base;
- Crie novos Tablespaces nas novas partições com o comando CREATE TABLESPACE;
- Utilize os comandos ALTER TABLE e ALTER INDEX com a opção SET
TABLESPACE para mover tabelas e índices para os novos Tablespaces; - Teste os dados no novo Tablespace;
- Restaure o acesso aos usuários;
Este procedimento é um pouco mais trabalhoso, pois exige que você indique tabela por tabela e índice por índice em qual Tablespace eles deverão ficar. No entanto, é a opção mais flexível, permitindo um ajuste de desempenho mais fino.
