É possível criar / restaurar rapidamente instantâneos de banco de dados com o PostgreSQL?

52

Primeiro de tudo, eu sou um desenvolvedor, não um DBA ou administrador de sistemas; por favor, seja gentil :)

Estou trabalhando em um fluxo de trabalho de aplicativos em que uma única ação do usuário acionará alterações complexas no banco de dados - criando centenas de registros em algumas tabelas, atualizando centenas de registros em outros, etc. No total, cerca de 12 tabelas ) são tocados por esta ação. Devido à complexidade, é muito difícil reverter manualmente todas as alterações antes que eu possa executar outro teste. Durante a maior parte do meu tempo de desenvolvimento, posso simplesmente inserir uma instrução "ROLLBACK" perto do final do fluxo de trabalho, mas quando chego perto de confirmar minhas alterações, preciso testar a realidade.

Eu tenho uma cópia local do banco de dados de produção para trabalhar. No meu caso, despejar e restaurar entre testes é mais rápido do que escrever um script para desfazer todas as alterações. É mais rápido, mas ainda está me deixando muito lento (a restauração leva cerca de 20 minutos no meu laptop antigo). Existe alguma maneira de salvar um instantâneo do estado atual do banco de dados e restaurá-lo rapidamente?

Tenho a garantia de ser o único usuário no sistema e tenho acesso root. O dump do banco de dados tem ~ 100 MB quando tar'ed e gzip'ed. A versão do PostgreSQL é 8.3.

Agradecemos antecipadamente por quaisquer idéias úteis.

Zilk
fonte
Você diz que tem o despejo de banco de dados, isso não é suficiente? Teste seu sistema, se algo der errado, use o dump para recuperar o banco de dados ao estado original e continuar desenvolvendo.
DrColossos
11
Você está restaurando apenas as tabelas que foram alteradas?
Jack Douglas
11
@ Jack Douglas: Estou restaurando o banco de dados completo do despejo. As tabelas em questão compõem cerca de 2/3 dos dados, e eu ainda teria que me preocupar com a ordem correta de restauração e restrições de chave estrangeira.
Zilk
11
@DrColossus: sim, os dumps são suficientes para restaurar o estado anterior, mas a criação e aplicação deles é muito lenta.
Zilk

Respostas:

35

Você pode usar instantâneos no nível do sistema de arquivos, mas isso geralmente é bastante complicado, precisa de sistemas de arquivos especiais e nem sempre está disponível, principalmente em laptops antigos. ;-)

Que tal criar seu estado base como um banco de dados e depois criar um novo banco de dados para sua execução de teste, usando a CREATE DATABASE ... TEMPLATEfuncionalidade Após o teste, você joga fora esse banco de dados. Então sua restrição de velocidade é essencialmente apenas o tempo para cp -Ro diretório do banco de dados. Isso é o mais rápido possível sem a mágica do instantâneo do sistema de arquivos.

Peter Eisentraut
fonte
Essa é uma ideia muito boa. Eu não tinha pensado em modelos de banco de dados. Obrigado!
Zilk
11
Essa é uma ótima solução, 5x mais rápida que a restauração suspensa, mas tem uma desvantagem: você precisa descartar as conexões atuais antes de fazer isso, caso contrário, ela falhará na execução.
Sorin
Atualização: isso não funcionará na produção porque o banco de dados de origem terá conexões com ele. Precisamos de outra solução.
22414
11

Use Stellar , é como o git para bancos de dados:

O Stellar permite restaurar rapidamente o banco de dados quando você está escrevendo, por exemplo, migrações de banco de dados, alternando ramificações ou alterando o SQL. PostgreSQL e MySQL (parcialmente) são suportados.

David Portabella
fonte
3
ou liquibase.org
David Portabella
O liquibase não o suporta como o Stellar, onde você pode trabalhar com o banco de dados (por exemplo, em testes de unidade) e pode ter que reverter para algum estado ou tempo marcado anteriormente.
Andreas Dietrich
Sons estelares como uma grande idéia, mas não está funcionando para mim
Orlando
5

Se seu banco de dados for executado no Virtualbox , você poderá facilmente salvar instantâneos e restaurar instantâneos do estado do banco de dados e do próprio SO em alguns segundos (ou 1-2 minutos se você realmente tiver muitos dados no banco de dados ou no SO ou muito pouca memória alocada para a máquina virtual) gratuitamente.

Na sua maioria dos casos, seria melhor instalar um linux leve (que um servidor Windows) para executar a máquina virtual em que o banco de dados está hospedado, desde que você mencione que você tem poucos recursos disponíveis no seu laptop.


No site de produção, eu uso os backups de captura instantânea do MediaTemple para obter o mesmo resultado (mas custa 20 $ por slot de backup e é específico para esse serviço de hospedagem na web , para que não seja adequado a você).

picos selvagens
fonte
Ah, deixa pra lá, eu não vi o seu comentário que menciona você já sabe sobre o virtualbox.
wildpeaks
3

Provavelmente não é a resposta que você está esperando, mas você considerou um nível mais baixo de captura de imagem - LVM, por exemplo?

Jack Douglas
fonte
Sim, isso veio à mente. Infelizmente, os snapshots do sistema de arquivos não são suportados pelo FS que estou usando atualmente (ext3). Outra opção seria configurar uma VM como o Virtualbox para as execuções de teste.
Zilk
2

Encontrei essa pergunta ao tentar fazer o mesmo e acabou usando o git no diretório de dados do postgresql. Descartar as alterações é tão fácil quanto:

git reset --hard
user92843
fonte
6
Isso não serve para bancos de dados grandes. Além disso, por que torturar o git com arquivos binários de tamanho variável?
RolandoMySQLDBA
0

Ainda outra opção que poderia ser experimentada seria realmente salvar uma cópia do diretório de dados do postgresql e apenas reescrever o diretório existente com a cópia quando você quiser restaurá-lo. Isso exigirá mais espaço no disco, mas definitivamente será mais rápido do que restaurar a partir de um backup. Não tenho certeza se isso seria mais rápido que o método do modelo, portanto, seria uma boa ideia fazer alguns testes primeiro.

Haroldo_OK
fonte
0

Embora eu tenha que dizer a solução Stellare git reset --hardseja interessante, terei um problema com bancos de dados e testes maiores e uso as Virtualboxsoluções etc., no entanto, em testes maiores, elas se tornam um pouco mais "problemáticas" quando você estão usando soluções bare metal etc.

Portanto, tenho que mencionar ZFScomo um sistema de arquivos a considerar para estes no futuro pelas seguintes razões que @ Peter Eisentraut também mencionou:

  1. Instantâneos - especialmente quando você faz a replicação do Prod para QA / DR, você pode usar o mesmo "sistema de arquivos" para os testes:
#On a replication node, rather stop, snap, restore for a "consistent" backup ;)
su -l -c "/usr/bin/m2ee stop" acw_qa
pg_ctlcluster ${=QA} stop --force
zfs destroy -R $SNAPSHOT
pg_ctlcluster ${=REPLICATION} stop --force
zfs snapshot $SNAPSHOT
pg_ctlcluster ${=REPLICATION} start

zfs destroy $CLONE
zfs clone -o mountpoint=$CLONEDIR $SNAPSHOT $CLONE
rm $CLONEDIR/$CLUSTER/recovery.conf
pg_ctlcluster ${=QA} start
su -l -c "/usr/bin/m2ee start" acw_qa
  1. para fazer um teste, logo antes do teste, o postgresql pára como acima, zfs snapshot $SNAPSHOTinicie o postgresql e, em seguida, faça o rollback, pare o postgresql e apenaszfs rollback $SNAPSHOT

  2. Compactação - O Postgresql recebe uma compactação típica de 3: 1 em meus bancos de dados, para que você possa fazer muitos testes;)

Hvisage
fonte