Create full backup (juju run postgresql-k8s/leader create-backup)
Restore it (juju run postgresql-k8s/leader restore backup-id=<your_value>)
Expected behavior
After successful restore, cluster should print message "Restore succeeded" in the debug-log and Patroni on-failure condition should be restored.
Actual behavior
Cluster appears in the "Move restored cluster to another S3 bucket" and it indicates, that restore process is finished. But there is no "Restore succeeded" message in the debug-log and Patroni on-failure condition isn't really restored - juju show-unit postgresql-k8s/0 shows related fields:
Although I can surely tell what commit exactly caused this issue in the VM version (see reference at the top), here PITR was implemented with these changes all from the beginning. I think this issue will be critical when working on Timelines management for the PITR.
github-actions[bot]
commented
1 month ago
This is the same bug I've encountered in VM version of this charm.
Steps to reproduce
juju run postgresql-k8s/leader create-backup)juju run postgresql-k8s/leader restore backup-id=<your_value>)Expected behavior
After successful restore, cluster should print message "Restore succeeded" in the debug-log and Patroni on-failure condition should be restored.
Actual behavior
Cluster appears in the "Move restored cluster to another S3 bucket" and it indicates, that restore process is finished. But there is no "Restore succeeded" message in the debug-log and Patroni on-failure condition isn't really restored -
juju show-unit postgresql-k8s/0shows related fields:Overall, it leads to the conclusion, that successful restore does not trigger all its events and does not restore cluster to the fully working state.
Versions
Operating system: Ubuntu 24.04 LTS
Juju CLI: 3.5.3-genericlinux-amd64
Juju agent: 3.5.3
Charm revision: 349
microk8s: MicroK8s v1.30.1 revision 6843
Log output
Juju debug log: k8s_is_restore_finished_backupid.log
Additional context
Although I can surely tell what commit exactly caused this issue in the VM version (see reference at the top), here PITR was implemented with these changes all from the beginning. I think this issue will be critical when working on Timelines management for the PITR.