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: | Raw Message | Whole Thread | 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 |