Re: PostgreSQL Point In Time Recovery

Поиск
Список
Период
Сортировка
От Gregory Haase
Тема Re: PostgreSQL Point In Time Recovery
Дата
Msg-id CAHA6QFTid8cD9uV1gzKb8mPG1bucHQb2aBhPpTv9mYjG9cS+Xg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PostgreSQL Point In Time Recovery  (Jayadevan <maymala.jayadevan@gmail.com>)
Список 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.jayadevan@gmail.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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

В списке pgsql-general по дате отправления:

Предыдущее
От: Jayadevan
Дата:
Сообщение: Re: PostgreSQL Point In Time Recovery
Следующее
От: Alan Nilsson
Дата:
Сообщение: Re: Segmentation fault: pg_upgrade 9.1 to 9.3: pg_dump: row number 0 is out of range 0..-1