Mysql tables missing after Docker update: "TableName doesn't exist in engine"

Question

A recent Docker update seems to have caused (just some) InnoDB tables in a MariaDB to not be accessible. I get:

#1932 - Table 'dbname.SomeTableName' doesn't exist in engine

when trying to access them (they do SHOW up in a table list). I've updated Docker (and the image) in the past with no problem. The db files and permissions look fine.

I could recreate just the "missing" tables (4 out of ~35) from a backup, but when I try to delete them I get:

#1347 - 'dbname.SomeTableName' is not VIEW

I'm using Docker image mariadb:10.2 (MariaDB-10.2.12+maria~jessie) with a bind-mount for persistent data storage as part of a local Docker-for-Mac dev environment. The docker-compose.yml file looks like:

mysql: image: mariadb:10.2 volumes: - ./data/mysql:/var/lib/mysql

I've never had this error before and cannot dump or export the unaccessible tables. Is there a way to restore or repair (or delete) them? I would rather not have to recreate the entire database.

Assibilate

Stack Overflow is a site for programming and development questions. This question appears to be off-topic because it is not about programming or development. See What topics can I ask about here in the Help Center. Perhaps Super User or Unix & Linux Stack Exchange would be a better place to ask. – Astatine

I think this squarely falls under "directly involve tools used primarily for programming", and there are plenty of other questions about MySql config here. – Assibilate

Actually, it does not. Docker is just another lightweight VM like Debian chroot's. Docker is supposed to be used for API questions, but Stack Overflow has become a dumping ground for the questions. – Astatine

Turns out it it was only indirectly a Docker problem, does that change things for you? Docker was just involved as it contributed to updating the MariaDB version -- similar to if it had been yum or apt. Again, I'm running a very common development setup so I have to think it's possible it's happened to some other people. – Assibilate

Answer 1

I was able to solve this by using a custom mysql config for my local and adding:

[mysqld]
lower_case_table_names=1

You can do this without changing your default config by mounting a file containing the text above into the mysql conf.d directory like:

volumes:
  - ./mysql_local.cnf:/etc/mysql/conf.d/mysql_local.cnf:ro

Assibilate

Since this solved the problem and it's one others may run into, not sure why you would downvote. – Assibilate

I ran into this problem after updating my Docker installation. I am really curious what might have caused this change. Any ideas? Reading the docs for the setting you have provided didn't shed too much light for me... dev.mysql.com/doc/refman/5.7/en/… – Regenerate

I was never able to definitively tell what caused it but I noticed the tables that were missing used upper-case letters (created by a 3rd-party module, mine are lower-case). I assume the Docker update triggered an image update and having data bind-mounted to a non-case sensitive volume while running on a case-sensitive one may have caused the issue. Why it wasn't a problem prior, I can't say. I did change my image to include the minor version, e.g., image: mariadb:10.2.12 -- although it's also possible the Docker update changed something related to the filesystem. – Assibilate

You can also fix this using adding the following entry command: --lower_case_table_names=1 – Geode

Sory, but this lower_case_table_names=1 option doesn't fix the issue. And my tables are in the lowercase already. – Mercedezmerceer

It works for me, thank you so much! I am running Docker in Mac OS and after altering table it breaks. My tables also contains uppercase letters. I added --lower_case_table_names=1 to command section in docker-compose.yml. – Wicket

Answer 2

Using Docker Desktop on MacOs Sonoma (14.3) and the same error appears after upgrading docker desktop to 4.29 version. The problem was fixed changing File sharing implementation for VirtioFS (instead of osxfs)

Yoheaveho