After starting the MySQL container, check the logs with docker logs -f mysql-docker and you will find it interrupts at the InnoDB initialization step:

mysql-docker | ... [System] [MY-013576] [InnoDB] InnoDB initialization has started.
mysql-docker exited with code 137 (restarting)

Exit Code 137 corresponds to the Linux signal 128 + 9 (SIGKILL), meaning the process was forcibly terminated by the Linux kernel's OOM Killer (Out-Of-Memory killer).

MySQL 8.0's default startup configuration has high memory requirements, and it pre-allocates a large Buffer Pool when initializing InnoDB. When the host's available memory is insufficient, the kernel kills the mysqld process consuming the most memory to prevent the system from going down.

Run the following command on the host to confirm whether it is a memory issue:

# 查看宿主机系统内核日志
dmesg -T | grep -i oom

# 查看 Docker 是否记录了 OOM
docker inspect mysql-docker --format='{{.State.OOMKilled}}'

If the output shows true or contains Killed process ... (mysqld), it is confirmed to be an out-of-memory condition.

[ERROR] [MY-012574] [InnoDB] Unable to lock ./ibdata1 error: 11

• Error 11 (EAGAIN / Resource temporarily unavailable): This means the data file ibdata1 has already been given a Write Lock by another process.
• Why it happens: When the previous container crashed suddenly due to OOM, orphan processes that had not fully exited may remain in the background; or, although the old container has stopped, the system still holds file handles to the mounted volume at a lower level.

Use lsof to see who is occupying ibdata1:

# 查出占用 ibdata1 的进程
lsof /var/lib/mysql/ibdata1

Example output:

COMMAND    PID            USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
mysqld  429692 systemd-coredump   9uW   REG  253,1 12582912 31823670 /var/lib/mysql/ibdata1

• Reading the flags: The W in 9uW stands for Write Lock, proving that PID 429692 has exclusive access to the file.
• User explanation: systemd-coredump is because the mysql user UID inside the Docker container (such as 999) is mapped to the corresponding account name on the host, further confirming that this is a leftover container process from the previous crash.

Force-kill the leftover mysqld process on the host:

# 1. 强杀残留进程
kill -9 429692

# 2. 清理旧容器
docker stop mysql-docker && docker rm mysql-docker

Running MySQL 8.0 in a low-memory environment requires limiting memory overhead. It is recommended to reduce the InnoDB buffer pool and disable Performance Schema:

• --innodb-buffer-pool-size=128M (or 256M): Lower the buffer pool to a reasonable range (the default is often 1G or more).
• --performance-schema=OFF: Disable performance monitoring, which can directly free up 200MB~400MB of memory.

If physical memory is only 1GB, it is recommended to add 2GB of Swap to prevent sudden memory spikes from being killed by OOM:

# 创建并启用 2GB Swap 文件
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# 永久生效（追加到 /etc/fstab）
echo '/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab