Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.4.6, 10.5, 10.6, 10.7(EOL), 10.8(EOL)
-
Official docker image. Running on multiple hosts, docker for desktop (windows 10 pro) and rancherOS
Description
I'm using the official MariaDB mariadb:10.4.6-bionic image and I have a problem: my tables corrupt themselves. This had happened at least four times this month:
- on two different dev machines using docker-compose
- on the staging machine using docker swarm
Everytime the symptom is that a table exists in the information schema but it can't be read or altered at all. Any operation leads to a 'Table does not exists in engine' error.
The container logs contain this error at startup:
[ERROR] InnoDB: Table sfdb.specialist contains unrecognizable instant ALTER metadata
I've checked the server system variables with
SHOW VARIABLES;
And alter_algorithm has the value DEFAULT which means (if I understand the documentation correctly) that it should not use the INSTANT algorithm, only INPLACE and COPY.
https://mariadb.com/kb/en/library/server-system-variables/#alter_algorithm
Trying to dig into the MariaDB codebase led me to this check:
https://github.com/MariaDB/server/blob/cccfa9dcfe2c161779824c01a84edfa64fc4378a/storage/innobase/btr/btr0cur.cc#L465
But I do not have enough knowledge of the inner workings of MariaDB to understand what is going on.
What am I doing wrong? Should I set some flag or configuration to have a stable database in docker?
PS: if this JIRA is not the correct place to ask this can you point me to a more suitable place to post my question ?
Attachments
Issue Links
- duplicates
-
MDEV-19916 Corruption after instant ADD/DROP and shrinking the index tree
- Closed
- is caused by
-
MDEV-15562 Instant DROP COLUMN or changing the order of columns
- Closed