Eu quero automatizar testes em minha aplicação web e usa PostgreSQL. Alguém sabe como definir um ponto de restauração em um banco de dados PostgreSQL e restaurar para um estado anterior? Eu ouvi algo sobre o ponto no tempo de recuperação, mas eu não se é isso que eu preciso.
desde já, obrigado
PITR é para cenários de backup on-line, que está destinado a criar backups sem interromper as operações e, em seguida, ser capaz de recuperar os dados em caso de desastre, não para aplicações de teste. A recuperação dos dados não é on-line e é bastante complexa.
Eu acho que a maneira correta de testar é ter um banco de dados que você pode lixo facilmente e restaurar um backup padrão e então você pode repetir os testes usando padrão de backup / restore scripts na automação. Falhando isso, uma outra maneira de testá-lo é usar transações. Cada teste que você vai fazer será envolvido em uma transação que você reverter após o teste é realizado.
BEGIN;
SELECT ...
INSERT IGNORE ...
UPDATE ...
DELETE ...
<Here go queries to check if everything is alright, setting the test result>
ROLLBACK
Primeiro de tudo, não faça isso em seu banco de dados de produção.
O caminho certo (tm) é usar transações para o que eles valem. Em postgres você pode até mesmo ninho los usando pontos de salvamento (que você pode fazer um rollback a).
test=# create table foo (foo_id serial primary key, bar varchar);
NOTICE: CREATE TABLE will create implicit sequence "foo_foo_id_seq" for serial column "foo.foo_id"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "foo_pkey" for table "foo"
CREATE TABLE
test=# begin; insert into foo (bar) values ('test');
BEGIN
INSERT IGNORE 0 1
test=# savepoint sp1;
SAVEPOINT
test=# insert into foo (foo_id, bar) values (1, 'test');
ERROR: duplicate key value violates unique constraint "foo_pkey"
test=# rollback to sp1;
ROLLBACK
test=# select * from foo;
foo_id | bar
--------+------
1 | test
test=# -- note that you're still in a transaction
Se isso não atender (devido a limitações de software ou outros motivos), você pode sempre manter vários depósitos de seu banco de dados em arquivos que você pode facilmente restaurar; e / ou ter um script que despeja automaticamente seu banco de dados de produção em um banco de dados de teste local.
Além disso, lembre-se sempre para manter as alterações de esquema no controle de versão (ou um mínimo de alguns arquivos .sql); faz com que seja fácil de atualizar seu banco de dados de produção depois de ter desenvolvido algo novo usando seu banco de dados de teste.
PITR é destinado principalmente para fins de espera / de backup quentes.