-
Notifications
You must be signed in to change notification settings - Fork 992
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detach a Postgres cluster from the operator temporarily #421
Comments
This change may need to be observed out of order, not sure how this could be done. But ideally it does not first apply all kind of pending changes on this cluster but stops sync immediately. In first round though this could always be achieved with manual operator restart. |
👍 Similar issue here. I have a 3-node cluster, and the first one is down because I got some EBS errors on an AWS M5 machine which rendered the volume read-only (dmesg here). I wanted to unmount the volume and do a A maintenance feature per cluster would be most useful. PS: for issues that don't require unmounting volumes one can simply use |
So maybe there are multiple levels of maintenance that can be expressed in the cluster manifest?
Not sure if this is the best approach or naming, just trying to underline the types of "detachment" out there. |
one special case to watch out is the incomplete rolling update
|
With #802 merged this could be realized via |
We were facing a situation where we needed to edit the statefulset of one cluster manually. This does not work while the operator is running and syncing objects.
We solved this by scaling operator to 0, but this is not ideal.
Suggest we look into the manifest to add something like:
sync: false
detach: true
maintenance: true
Or similar.
The text was updated successfully, but these errors were encountered: