Issue with MySQL 5.7 Docker Containers Failing to Restart
Hello,
My team and I encountered an issue this week with containers running the MySQL 5.7 image from Dockerhub. After shutting them down, the containers failed to restart.
We’ve been using this same unmodified image across multiple containers for over a year without issue, but this problem started earlier this week.
This same issue also occurs across different cloud providers in our account. And the problem persists even when deploying the same MySQL 5.7 image to a new container, so this isn’t isolated to a single container.
Here are the errors displayed when attempting to restart the container:
2024-09-20715:38:38.264529Z 0 [Warning] A deprecated TLS version TLSvl. 1 is enabled. Please use TLSv1.2 or higher.
2024-09-20715:38:38.265036Z 0 [Warning] CA certificate ca.pem is self signed.
2024-09-20715:38:38.265070Z 0 [Note] Skipping generation of RSA key pair as key files are present in data directory.
2024-09-20715:38:38.265316Z 0 [Note] Server hostname (bind-address): '*'; port: 3306
2024-09-20T15:38:38.265348Z 0 [Note] IPv6 is available.
2024-09-20715:38:38.265360Z 0 [Note]
2024-09-20T15:38:38.265383Z 0 [Note] Server socket created on IP: ' :: '.
2024-09-20715:38:38.265425z 0 [ERROR] Could not create unix socket lock file /var/run/mysqld/mysqld.sock.lock.
2024-09-20715:38:38.265435Z 0 [ERROR] Unable to setup unix socket lock file.
2024-09-20715:38:38.265445Z 0 [ERROR] Aborting
We are able to solve this issue by upgrading to a new MySQL 8 image.
Could the TLS errors be related to CycleOS? Was there an update that potentially disables older versions of TLS?
Any guidance would be greatly appreciated!
Hi Andrew,
We tested mysql 5.7 on both our old kernel (5.15.x) and new kernel we pushed out earlier this week (6.6.x) and were unable to replicate. It sounds like you were able to resolve by upgrading your MySQL image, but if you have any other databases that are currently experiencing this issue, we'd be happy to dive in deeper to those specific instances.
Thanks!
Thanks for following up! Luckily upgrading the MySQL image was pretty easy so we should be good for now. I will let you know if this happens again.
Hey Andrew,
We were able to get much more clarity into the cause of the issue.
The image that was imported was mysql5.7 which in itself is completely fine, but because of how long ago the image you were using was imported you ended up hitting a latent bug in an older version that has since been patched.
For example, importing the official mysql:5.7 will always pull the latest release of that version.
When you pulled it, it could have been 5.7.1, and more recently when we pulled it, it may have been 5.7.44.
When you upgraded to mysql:8, you had roughly the same experience you would have had just re-importing a new mysql:5.7 image and reimaged the container.
Hope this is a helpful explanation, please let me know if you'd like to dive deeper on any part of it :)