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
Easiest way to reproduce this behaviour is to create a new cluster with volumeSpec.emptyDir: {} and a few replicas, and delete the my-cluster-mysql-0 pod.
The text was updated successfully, but these errors were encountered:
I have made a 3-node mysql cluster to have a play around with mysql-operator
When draining the node containing
mysql-0
, it seems to be unable to restore from a sibling/master in the cluster after the pod has been rescheduled on another node.When inspecting, the sidecar errors with this message
https://github.com/presslabs/mysql-operator/blob/c26526ee7be6e22d0f2825e7ce33ae71781b87e3/pkg/sidecar/appclone/appclone.go#L73
Since i am using
emptyDir
, theclone-mysql
sidecar should download from the current master, or a sibling, but due to theserverId
being100
, it goes straight to the error-message above.https://github.com/presslabs/mysql-operator/blob/c26526ee7be6e22d0f2825e7ce33ae71781b87e3/pkg/sidecar/appclone/appclone.go#L65
It seems some kind of recovery option for pod 0 is needed.
I would suggest something along the lines of this
I dont think this will result in the pod trying to connect to itself for recovery, due to this check above
https://github.com/presslabs/mysql-operator/blob/c26526ee7be6e22d0f2825e7ce33ae71781b87e3/pkg/sidecar/appclone/appclone.go#L52
Easiest way to reproduce this behaviour is to create a new cluster with
volumeSpec.emptyDir: {}
and a few replicas, and delete themy-cluster-mysql-0
pod.The text was updated successfully, but these errors were encountered: