docker update 后，Mysql 未在 MacOS 上的 docker 容器中启动

Question

I just upgraded to Docker Desktop 2.4 on MacOS, from version 2.3. Suddenly none of my mysql containers will start. The logs show this as the reason:

Different lower_case_table_names settings for server ('2') and data dictionary ('0').
Data Dictionary initialization failed.
Aborting

The database files are mounted in a volume on my host machine, so that they persist between restarts.

I finally figured out why. Posting in order to answer.

Answer 1

With the latest docker you can disable the gRPC Fuse for file sharing. (the gRPC Fuse setting is causing this problem, it's incompatible with the data dictionary of 0)

This fixes the problem... You can stop here if you're happy, but to use the new filesystem you can:

• Disable this checkbox
• Start the container
• Dump the database
• Enable this checkbox
• Make sure your data folder empty (so mysql creates a new data dictionary)
• Import the dumped database

UPDATE

Since version 2.5, the setting has been moved to the 'experimental features' page:

Answer 2

The lower_case_table_names setting tells mysql how to store and compare table names. If the file system the database is stored on is itself not case-sensitive, it will force you to use lower_case_table_names=2 .

The MacOS filesystem is not case-sensitive. Up until Docker Desktop 2.4, the mysql container apparently didn't know that the underlying filesystem is not case-sensitive and set lower_case_table_names=0 . However, since upgrading to Docker 2.4, Docker is apparently smarter about how it mounts volumes. So the container realizes its running on a case-insensitive filesystem and forces lower_case_table_names=2 . The problem is that you cannot change the value of lower_case_table_names after initializing the database. And since the data dictionary was initialized with lower_case_table_names=0 , it will fail to initialize with the server set to lower_case_table_names=2 .

The only solution I've found is to:

1. Downgrade to Docker Desktop 2.3
2. Backup the entire database
3. Upgrade to Docker 2.4
4. Delete the volume storing the database.
5. Reinitialize the database.
6. Restore the database from backup.

UPDATE: See this answer below for a better solution. There is apparently no need to downgrade. You can instead disable "gRPC Fuse for filesharing", backup the database, re-enable gRPC fuse, delete your database data folder, and restore the database from backup.

Answer 3

Another option is to create a case sensitive APFS volume using Disk Utility.

Unlike a partition, it is possible to share the free space, so you don't need to worry about reserving enough space to run your database.

Then create a symlink from your project to your case sensitive volume.

cd ~/my-project
ln -s /Volumes/MySQL/project-db mysql

Answer 4

Docker removed this option on the recent updates , i manage to solve this issue on windows by doing this

Run a shell as administrator:

go to your local mounted mysql volume and run

fsutil file setCaseSensitiveInfo ./ enable 

credits to https://github.com/docker/for-win/issues/12384#issuecomment-972845031

Answer 5

A small addition to Loic's H answer. Suppose your mapping is something like this:

docker run --name your_container_name ... -v //d/MySqlDockerData:/var/lib/mysql ...

if your try

fsutil file setCaseSensitiveInfo d:\MySqlDockerData

you will get an error "The directory is not empty"

To get around this follow these steps:

1. run docker container stop your_container_name
2. transfer the contents of the folder to the another place (clear the folder)
3. run again fsutil file setCaseSensitiveInfo d:\MySqlDockerData
4. transfer back saved data to the d:\MySqlDockerData
5. run docker container start your_container_name

voila

Answer 6

As workaround on Windows OS I disabled WSL in Docker Desktop and it helped me

Update . After last Docker Desktop Updates I was forced to set Windows directory with DB data as case sensitive