| From: | Rui DeSousa <rui(at)crazybean(dot)net> |
|---|---|
| To: | Steven Crandell <steven(dot)crandell(at)gmail(dot)com> |
| Cc: | Srinath Ganesh <sganesh(at)galaxiasol(dot)com>, pgsql-admin(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Postgres PITR: Recovery does not seem to fetch from Archive Dir |
| Date: | 2019-08-22 15:24:23 |
| Message-ID: | 3A601DDD-E550-4E60-A07A-52BFE19D3120@crazybean.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
> Dummy Data
>
> create table testPITR1 as select * from pg_class, pg_description;
> select * from current_timestamp;
Is this timestamp used in the recovery?
> Kill existing db
>
> /usr/lib/postgresql/11/bin/pg_ctl -D /home/admin-12/Desktop/test2 -l /home/admin-12/Desktop/test2.log stop
> mv test2 test2.bad
> tar -xvzf test2.tar
> sudo chown -R postgres:postgres test2
This is a normal shutdown, thus the WAL file should have been archive; was the latest WAL file archive?
> Recovery conf
>
> nano /home/admin-12/Desktop/test2/recovery.conf
>
> restore_command = 'cp /home/admin-12/Desktop/test2_wal/%f %p'
> recovery_target_time = '2019-08-21 16:14:11.175781+05:30’
If this timestamp was used from the prior step; then the tables testPITR2, testPITR3, and testPITR4 should not be restored as they where created after the given timestamp.
> WITHOUT THIS STEP I CANNOT RECOVER Table 2,3,..
>
> cp test2.bad/pg_wal/0* test2/pg_wal/
> Any tips?
>
What is you recovery process after issuing the cp command, a restore without recovery_target_time?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | soumik.bhattacharjee | 2019-08-22 15:25:50 | RE: Postgres DB Slowness |
| Previous Message | Holger Jakobs | 2019-08-22 15:15:51 | RE: Postgres DB Slowness |