MySQL Container "ready for connections" Race in CI

On first boot the MySQL image starts a temporary server to run init scripts (printing "ready for connections"), shuts it down, then starts the real server (printing it again). Connecting during the temporary phase races the real startup and fails intermittently.

What this error means

MySQL-backed CI jobs fail intermittently with connection or access errors early in the run, then pass on retry. The container logs show "ready for connections" appearing twice - only the second is the real server.

mysql

[Server] /usr/sbin/mysqld ... ready for connections. (init phase)
... mysqld will now restart ...
[Server] /usr/sbin/mysqld ... ready for connections. (real server)

Common causes

Connecting during the init-phase server

The first "ready for connections" is the temporary init server. A client that connects then may be cut off when it shuts down to start the real server.

No robust readiness probe

A naive log-grep or short sleep can latch onto the first readiness message and proceed too early.

How to fix it

Probe with a real query loop

Loop on an actual ping/query so a momentary drop during the restart is retried rather than fatal.

Terminal

for i in $(seq 1 30); do
  mysqladmin ping -h 127.0.0.1 -P 3306 --silent && \
    mysql -h 127.0.0.1 -uroot -p"$MYSQL_PWD" -e 'select 1' && break
  sleep 2
done

Use the service healthcheck with retries

.github/workflows/ci.yml

options: >-
  --health-cmd "mysqladmin ping -h 127.0.0.1 --silent"
  --health-interval 5s --health-timeout 5s --health-retries 15

How to prevent it

Probe MySQL readiness with a real query, tolerating one drop during the init restart.
Give the healthcheck generous retries to outlast first-boot initialization.
On managed runners (Latchkey), self-healing auto-retries this kind of transient first-boot drop automatically.