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
Hi, when working with MySQL clusters deployed via MOCO, I've noticed an interesting behavior regarding backup status persistence:
Once a MySQL cluster has been backed up, the .status.backup field in the custom resource gets populated
If backups are completely disabled afterward, this field remains populated with the last backup information
There seems to be no straightforward way to reset this field to its initial empty state (as if no backup had ever occurred)
Current Situation:
The .status.backup field persists even after disabling backups in MOCO
This prevents returning to a "clean slate" backup status
The only known solution appears to be recreating the entire cluster
Question:
Is there any way to reset the .status.backup field to its initial state without having to recreate the entire MySQL cluster in Kubernetes?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi, when working with MySQL clusters deployed via MOCO, I've noticed an interesting behavior regarding backup status persistence:
Once a MySQL cluster has been backed up, the
.status.backup
field in the custom resource gets populatedIf backups are completely disabled afterward, this field remains populated with the last backup information
There seems to be no straightforward way to reset this field to its initial empty state (as if no backup had ever occurred)
Current Situation:
The .status.backup field persists even after disabling backups in MOCO
This prevents returning to a "clean slate" backup status
The only known solution appears to be recreating the entire cluster
Question:
Is there any way to reset the
.status.backup
field to its initial state without having to recreate the entire MySQL cluster in Kubernetes?Beta Was this translation helpful? Give feedback.
All reactions