-
Notifications
You must be signed in to change notification settings - Fork 9.1k
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
mysql chart: crashloopbackoff after node restart #743
Comments
I have the same issue on k8s 1.10 |
Thanks for raising this up! I was able to reproduce the error. It seems that it's not setting the right permissions on the directory /opt/bitnami/mysql/logs/ when it starts MySQL container with persisted data (the one stored on the Persistent Volume claimed by the MySQL statefulset). @javsalgar does it make sense to you? |
It looks to me that it could be due to the minikube start up process that may change the permissions in the folders where the persistent volumes are stored. I would report this issue in minikube as they may have more information. |
@javsalgar @juan131 I don't see any volume mount defined for the path that you specified. The statefulset has the following in
|
What information should I provide to the minikube team? |
Hi @rmorrise as you mentioned it also happens when persistence is disabled.... I could workaround the issue by deleting manually the pods so the statefulset automatically creates new pods that seem to be working fine...
That's pretty weird and I guess it must be related with some weird behaviour on Statefulsets. Do you have any clue @javsalgar ? |
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback. |
Unfortunately I still have this issue on Google Kubernetes v1.10.7-gke.11. Somehow master pod was restarted then it gets CrashLoopBackOff forever. Here is the log:
|
It could be related with some incomplete initialisation of MySQL.. Are you using persistence or did you disable it? Could you share the exact command you used to deploy the chart in order to reproduce it? Could you share the initialisation logs too? |
Hi @juan131 , I just used Helm to install chart
I tried to delete master pod, Kubernetes nodes...but I can't reproduce this issue anymore.
I fixed CrashLoopBack issue by deleting PVC and install new one, so I can not access logs. |
It looks like a problem during the initialisation. Something went wrong and the data in the PVC was inconsistent. I'm glad you could solved the issue by deleting the PVC! Please let me know if you need further help with it. |
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback. |
Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary. |
* circleci: improve version check * circleci: add chart releaser orb
I'm also running into this issue; using mysql:
inside: true
fullnameOverride: my-mysql
auth:
database: mine
username: me
password: pwd
rootPassword: root
image:
tag: 8.0.11
registry: docker.io
repository: bitnami/mysql After I uninstall/reinstall a couple of times, I end up with the
|
Hi @HebeHH Why did you overwrite the default As you can see in the "Notable Changes" section below: The Bitnami MySQL image introduced structural changes in the |
Hi @juan131 , Thanks for the pointers! I was using I appreciate the help, it was severely puzzling me. |
You're welcome @HebeHH Please share with us your progress and let us know if you need anything else. |
I installed the mysql chart in minikube (win64) with the following YAML settings:
Chart starts up fine.
I stop and start minikube, and the chart doesn't run anymore. Both master and slave pods are getting a CrashLoopBackOff (Terminated: Error).
The master pod has the following in the log:
I think the root password is also different than on the previous run. I feel like this might be strange behavior? But I don't know if it's related to the crashing issue.
The text was updated successfully, but these errors were encountered: