首次运行Docker脚本无法执行SQL Dump，二次运行正常的问题排查

Hey there, let's break down what's happening here and fix this step by step!

The Root Cause of Your Issue #

The problem boils down to timing: When you first start the MySQL container, it goes through an initialization process—creating the specified user, database, and setting up permissions. Your dump.sql execution script is trying to connect before this process fully completes, especially before the userxx account's permissions are fully applied to localhost connections.

On the second run, the container's MySQL instance is already fully initialized, all permissions are active, so the script connects and runs without issues.

Solution 1: Make Your Script Wait for MySQL to Be Fully Ready #

You need to add a check to ensure MySQL is accepting connections before running your dump. Here's a simple bash script loop you can use:

#!/bin/bash
# Wait until MySQL responds to a connection attempt
until mysql -h 127.0.0.1 -u userxx -p'your_user_password' -e "SELECT 1"; do
  echo "Waiting for MySQL to finish initialization..."
  sleep 2
done

# Now execute the dump once MySQL is ready
mysql -h 127.0.0.1 -u userxx -p'your_user_password' your_target_database < dump.sql

Note: Using 127.0.0.1 instead of localhost can avoid socket-based connection quirks that sometimes cause permission mismatches in Docker environments.

Solution 2: Use the Official MySQL Image's Built-In Initialization Directory #

This is the most reliable approach—official MySQL Docker images automatically run scripts placed in /docker-entrypoint-initdb.d/ after the database is fully initialized (users created, permissions set up, etc.).

Option A: Mount the Dump File at Runtime

Just mount your dump.sql directly into the initialization directory when starting the container:

docker run -d \
  -e MYSQL_ROOT_PASSWORD=your_root_pass \
  -e MYSQL_USER=userxx \
  -e MYSQL_PASSWORD=your_user_pass \
  -e MYSQL_DATABASE=your_target_db \
  -v $(pwd)/dump.sql:/docker-entrypoint-initdb.d/dump.sql \
  mysql:latest

The container will automatically import dump.sql into your_target_db on its first startup.

Option B: Package the Dump into a Custom Image via Dockerfile

If you want to bake the dump into your image, here's the correct Dockerfile structure (this fixes the issues you had earlier with your failed Dockerfile attempt):

FROM mysql:latest

# Copy your dump file into the official initialization directory
COPY dump.sql /docker-entrypoint-initdb.d/

# Set required environment variables (can also pass these at runtime)
ENV MYSQL_ROOT_PASSWORD=your_root_pass
ENV MYSQL_USER=userxx
ENV MYSQL_PASSWORD=your_user_pass
ENV MYSQL_DATABASE=your_target_db

Build and run the image:

docker build -t custom-mysql .
docker run -d custom-mysql

Key Notes for This Method:

• Scripts in /docker-entrypoint-initdb.d/ only run on the first container startup (when the data volume is empty). If you re-run the container with existing data, the scripts won't execute—this aligns with your observation that the second run works.
• The image supports .sql, .sql.gz, and .sh files, executed in alphabetical order.

Why Your Earlier Dockerfile Attempt Failed #

Chances are one of these issues tripped you up:

• You tried to run the dump using a RUN command in the Dockerfile—this executes during image build, when the MySQL service isn't even running, so it can't connect.
• You didn't set the MYSQL_DATABASE environment variable, so the dump had no target database to import into.
• Your script used localhost for connections during initialization, which can hit socket permission issues before the container's MySQL setup is complete.

内容的提问来源于stack exchange，提问作者noitse