Обсуждение: Recovery/Rollback question

Hi,

I am new to the list and want to say "hello" first.
We are migrating to Postgres and therefore my question might be simple for
you.
We run several application databases under one db server. Now we are looking
for a mechanism to rollback unwanted user command without impact for other
databases. Is there a posiibilty to use something like WAL on tablespaces or
databases not only on db servers?
Does Postgres provide other utilities for this? Which strategies to you use?
Scenatio running databases a and b under the server.
It is now 10 o 'clock, user made a mistake at 8 o'clock  in database a, so
we need to roll database a back to 8 o'clock, database b keeps current data
status.
How do you solve this under Postgres?  Any links to useful docu chapters ?

Regards,
A.Stejskal

This is currently unsupported in mainstream PostgreSQL, as the WAL only
works on the cluster basis. The only options you currently have for
performing this is to use the last full backup and copies of WAL files
to restore the cluster on a second server to your specific point in
time, and restore that copy of the database in question to your primary
server.


Jason Minion
jason.minion@sigler.com


-----Original Message-----
From: pgsql-admin-owner@postgresql.org
[mailto:pgsql-admin-owner@postgresql.org] On Behalf Of
Antje.Stejskal@ppimedia.de
Sent: Monday, February 26, 2007 7:57 AM
To: pgsql-admin@postgresql.org
Subject: [ADMIN] Recovery/Rollback question

Hi,

I am new to the list and want to say "hello" first.
We are migrating to Postgres and therefore my question might be simple
for you.
We run several application databases under one db server. Now we are
looking for a mechanism to rollback unwanted user command without impact
for other databases. Is there a posiibilty to use something like WAL on
tablespaces or databases not only on db servers?
Does Postgres provide other utilities for this? Which strategies to you
use?
Scenatio running databases a and b under the server.
It is now 10 o 'clock, user made a mistake at 8 o'clock  in database a,
so we need to roll database a back to 8 o'clock, database b keeps
current data status.
How do you solve this under Postgres?  Any links to useful docu chapters
?

Regards,
A.Stejskal


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq

On Mon, 2007-02-26 at 07:57, Antje.Stejskal@ppimedia.de wrote:
> Hi,
>
> I am new to the list and want to say "hello" first.
> We are migrating to Postgres and therefore my question might be simple for
> you.
> We run several application databases under one db server. Now we are looking
> for a mechanism to rollback unwanted user command without impact for other
> databases. Is there a posiibilty to use something like WAL on tablespaces or
> databases not only on db servers?
> Does Postgres provide other utilities for this? Which strategies to you use?
> Scenatio running databases a and b under the server.
> It is now 10 o 'clock, user made a mistake at 8 o'clock  in database a, so
> we need to roll database a back to 8 o'clock, database b keeps current data
> status.
> How do you solve this under Postgres?  Any links to useful docu chapters ?

You can solve it with PITR (point in time recovery) but note that it
will roll back the whole cluster, not just one db in it.  However, PITR
is generally run on a secondary server, so that's ok.  If you're not set
up for PITR, you've asked a little late (i.e. after the fact is too
late) as it needs to be setup ahead of time normally.  You might want to
set up your machine to do PITR, but you need an image of your database
files from before the pebcak* incident.

Your users need to learn how to use transactions.  You can run some
pretty big transactions and roll them back if you don't like the
changes.  Once you commit though, you can't roll it back without using
disaster recovery techniques like PITR.

Look up PITR in the docs, it's a useful piece of kit.

*pebcak:  Problem exist(s|ed) between chair and keyboard.

On Mon, 2007-02-26 at 13:15 -0600, Jason Minion wrote:
> This is currently unsupported in mainstream PostgreSQL, as the WAL only
> works on the cluster basis. The only options you currently have for
> performing this is to use the last full backup and copies of WAL files
> to restore the cluster on a second server to your specific point in
> time, and restore that copy of the database in question to your primary
> server.

I'll take that as a request for a TODO item, for 8.4

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com