Re: PostgreSQL Point In Time Recovery

From: Gregory Haase <haaseg(at)onefreevoice(dot)com>
To: Jayadevan <maymala(dot)jayadevan(at)gmail(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: PostgreSQL Point In Time Recovery
Date: 2013-10-26 06:23:29
Message-ID: CAHA6QFTid8cD9uV1gzKb8mPG1bucHQb2aBhPpTv9mYjG9cS+Xg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Before going through something like delayed replication, you really want to
consider using zfs or lvm and taking regular snapshots on your hot or warm
standby. In the event of the accidental table drop, you can just roll back
to the snapshot prior and then do PITR from there.

Greg Haase

On Fri, Oct 25, 2013 at 11:14 PM, Jayadevan <maymala(dot)jayadevan(at)gmail(dot)com>wrote:

> Alan Hodgson wrote
> > Well, yeah. The point was that you possibly could run it for a while to
> > "catch
> > up" without taking a new base backup if you desired. You should also keep
> > copies of it for PITR.
>
> Something like this -
> delayed replication
> <http://dev.mysql.com/doc/refman/5.6/en/replication-delayed.html> might
> help. I could say lag by 12 hours, or 10000 transactions...
>
>
>
> --
> View this message in context:
> http://postgresql.1045698.n5.nabble.com/PostgreSQL-Point-In-Time-Recovery-tp5775717p5775997.html
> Sent from the PostgreSQL - general mailing list archive at Nabble.com.
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Alan Nilsson 2013-10-26 06:28:11 Re: Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1
Previous Message Jayadevan 2013-10-26 06:14:42 Re: PostgreSQL Point In Time Recovery