You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please, answer some short questions which should help us to understand your problem / question better?
Which image of the operator are you using? registry.opensource.zalan.do/acid/postgres-operator:v1.6.3
Where do you run it - cloud or metal? Kubernetes or OpenShift? Bare Metal K8s
Are you running Postgres Operator in production? yes
Type of issue? Bug report
I truncated the wrong schema in a production database (as smart people do) and I am trying to do a point-intime recovery.
I was able to recreate a backup cluster on a different namespace, and I am to see that data. Want I want to do is make sure that no data is missed between the time I recovered to the time I truncated. I can't figure out the exact time I did the truncate using pg_waldump so I decided to step one second by modifying clone.timestamp 1 second at a time unless I can't find the data. But it seems like changing the timestamp and re-applying the crd doesn't d the trick. And deleting and recreating the crd, takes too long because it needs to re-download and extract the base backup...
Is there a smarter way to creep forward until I reach the correct timestamp ? Could the operator be fixed to do that as one would expect ?
The text was updated successfully, but these errors were encountered:
Please, answer some short questions which should help us to understand your problem / question better?
I truncated the wrong schema in a production database (as smart people do) and I am trying to do a point-intime recovery.
I was able to recreate a backup cluster on a different namespace, and I am to see that data. Want I want to do is make sure that no data is missed between the time I recovered to the time I truncated. I can't figure out the exact time I did the truncate using
pg_waldump
so I decided to step one second by modifyingclone.timestamp
1 second at a time unless I can't find the data. But it seems like changing the timestamp and re-applying the crd doesn't d the trick. And deleting and recreating the crd, takes too long because it needs to re-download and extract the base backup...Is there a smarter way to creep forward until I reach the correct timestamp ? Could the operator be fixed to do that as one would expect ?
The text was updated successfully, but these errors were encountered: