Existem basicamente três maneiras de atualizar o PostgreSQL de diferentes versões principais (por exemplo, 9.1 a 9.3).
Fazendo upgrade com pg_dump
O primeiro, e recomendado se possível, é fazer um dump da versão antiga (9.1) usando o binário da versão mais recente (9.3) e restaurá-lo em um novo cluster criado para a versão mais recente.
Essa abordagem é, geralmente, a mais lenta, mas também a mais viável. Uma dica para torná-lo mais rápido é usar simultaneidade. Para despejar com trabalhos paralelos, você pode:
$ pg_dump --format=directory --jobs=4 --no-synchronized-snapshots --file=/path/to/mydump mydatabase
Você precisará fazer isso para cada banco de dados que tiver, ajustar o --jobs=4
valor para qualquer valor (teste alguns valores de 2 a número de núcleos e veja qual dá melhor velocidade). Além disso, durante esta fase, ninguém deve estar conectado ao banco de dados, qualquer modificação resultará em um dump corrompido (devido à opção não segura --no-synchronized-snapshots
).
Depois disso, você pode restaurar o despejo na nova instância usando pg_restore
:
$ createdb <options> -T template0 mydatabase
$ pg_restore --exit-on-error --jobs=4 --dbname=mydatabase /path/to/mydump
Depois disso, é recomendável executar ANALYZE
no seu banco de dados:
$ vacuumdb --analyze-only mydatabase
(se você puder pagar o tempo, execute apenas --analyze
também VACUUM
o banco de dados e atualize os mapas de visibilidade)
Atualizando com pg_upgrade
Outra opção, é usar o contribpg_upgrade
. Usando o --link
método, ele fornece uma maneira muito rápida de atualizar o PostgreSQL.
Antes de usar, é necessário fazer um backup de todo o diretório de dados, pois, no --link
modo, se algo der errado, você poderá perder os dados (novos e antigos). Além disso, leia todos os documentos e especialmente as notas na parte inferior (existem algumas limitações para pg_upgrade).
ATUALIZAÇÃO: Por favor, use a --check
opção antes de executar o comando definitivo. Além disso, para bancos de dados grandes, é recomendável executar este comando em uma sessão de tela.
Atualizar usando uma ferramenta de replicação baseada em gatilho
Outra opção para atualizar uma versão é usar uma ferramenta de replicação baseada no gatilho. Como Slony, Bucardo e Londiste.
Essa é a opção que requer o menor tempo de inatividade possível, mas é a mais difícil de se trabalhar.
Para fazer isso, você precisa construir um master-slave onde o master é sua versão atual (9.1) e o slave é a nova versão (9.3). Então, espere a primeira sincronização (com o sistema ainda em produção), depois feche todos os usuários conectados ao banco de dados (o tempo de inatividade começa aqui), aguarde o escravo recuperar o atraso, promova-o (o escravo) para dominar e redirecione todos os clientes / aplicativos para esta nova versão. E você terminou.
A documentação do Slony fornece um passo a passo para atualizar o PostgreSQL usando o Slony .
Qual escolher
Bem, como sempre depende, continuando:
- O dump + restore é o mais confiável, mas geralmente o mais lento (o paralelismo pode dar bons resultados)
- O pg_upgrade é uma das melhores opções para pouco tempo de inatividade (se você pode usar, veja as limitações), geralmente leva apenas alguns minutos, mesmo para grandes bancos de dados
- A replicação do gatilho é, sem dúvida, a que oferece o menor tempo de inatividade possível (quase zero), mas é realmente difícil de alcançar e eu recomendo apenas para pessoas experientes (no PostgreSQL e na ferramenta de replicação).
Espero poder ajudar. Boa sorte.