Comments on: Faster Point In Time Recovery (PITR) in PostgreSQL Using a Delayed Standby https://www.percona.com/blog/faster-point-in-time-recovery-pitr-postgresql-using-delayed-standby/ Wed, 20 Nov 2019 17:38:05 +0000 hourly 1 https://wordpress.org/?v=6.5.2 By: ADAM https://www.percona.com/blog/faster-point-in-time-recovery-pitr-postgresql-using-delayed-standby/#comment-10971465 Wed, 20 Nov 2019 17:38:05 +0000 https://www.percona.com/blog/?p=50738#comment-10971465 Your posts are very good … I understand the real use of delayed standby and how we can do PITR quickly….thanks…

Can we do snapshot standby and After testing revert to previous state to continue syncing with primary?which available in oracle.

]]> By: avivallarapu https://www.percona.com/blog/faster-point-in-time-recovery-pitr-postgresql-using-delayed-standby/#comment-10969477 Fri, 27 Jul 2018 13:05:19 +0000 https://www.percona.com/blog/?p=50738#comment-10969477 Sometimes, depending on the requirement, we may choose a larger delay time. For example, let us say, a Standby is delayed by a day or several hours. If you see huge amount of WALs that cannot be stored on the disk, you may have your retention policies on the number of WALs on your Disk. So you rather use restore_command to fetch those WALs.

]]> By: Cervisia https://www.percona.com/blog/faster-point-in-time-recovery-pitr-postgresql-using-delayed-standby/#comment-10969471 Thu, 26 Jul 2018 12:34:08 +0000 https://www.percona.com/blog/?p=50738#comment-10969471 Why the restore_command? Is there any case where the standby server would not already have all the required WAL entires?

]]> By: avivallarapu https://www.percona.com/blog/faster-point-in-time-recovery-pitr-postgresql-using-delayed-standby/#comment-10969360 Mon, 09 Jul 2018 13:36:28 +0000 https://www.percona.com/blog/?p=50738#comment-10969360 Absolutely. There are several backup solutions available to help us with PITR.
1. pg_basebackup + Continuous Archiving
2. pgBarman
3. pgBackRest

However, this is a completely different approach that allows us to recover to a certain point in time by just replaying a few WALs and can be considered much faster than all the 3 options mentioned above.

]]> By: saz https://www.percona.com/blog/faster-point-in-time-recovery-pitr-postgresql-using-delayed-standby/#comment-10969359 Mon, 09 Jul 2018 10:06:16 +0000 https://www.percona.com/blog/?p=50738#comment-10969359 Or just use https://www.pgbarman.org/

]]> By: avivallarapu https://www.percona.com/blog/faster-point-in-time-recovery-pitr-postgresql-using-delayed-standby/#comment-10969343 Tue, 03 Jul 2018 11:21:09 +0000 https://www.percona.com/blog/?p=50738#comment-10969343 Yes, this solution works good for recovering an Individual Table. Considering that you have a Delayed Standby(at least delayed by 1 hour) :
1. Recover the delayed Standby until 9:00am(using these steps)
2. Take a Dump of this Table from Delayed Standby and restore it on Master.
3. This way, you get your Table back and you should not loose data.

Much much faster when compared to a full Cluster PITR and lowest possible downtime.

]]> By: kc https://www.percona.com/blog/faster-point-in-time-recovery-pitr-postgresql-using-delayed-standby/#comment-10969342 Tue, 03 Jul 2018 08:29:04 +0000 https://www.percona.com/blog/?p=50738#comment-10969342 is there any way to flashback table level? suppose I have dropped one table at 9AM and notices at 9:15. If I do the above steps I can recover till 9AM(befor the drop command).. but I will loose 15 min data right?

]]> By: Konstantin Kondakov https://www.percona.com/blog/faster-point-in-time-recovery-pitr-postgresql-using-delayed-standby/#comment-10969332 Fri, 29 Jun 2018 17:10:43 +0000 https://www.percona.com/blog/?p=50738#comment-10969332 That’s very important update and safety measure. Must read for all DevOps. Bookmarked..

]]> By: Riyaz Uddin https://www.percona.com/blog/faster-point-in-time-recovery-pitr-postgresql-using-delayed-standby/#comment-10969329 Fri, 29 Jun 2018 03:19:02 +0000 https://www.percona.com/blog/?p=50738#comment-10969329 Excellent Post

]]>