Upgrade from Chevereto 4.4.2 to 4.5 failed – MariaDB → MySQL 8 migration issue

[bbq001]

Hi,

I'm upgrading an existing Chevereto 4.4.2 installation to Chevereto 4.5.

My installation uses the official Chevereto Docker setup and the provided Makefile. I followed the official Chevereto upgrade instructions here:

Install Chevereto on Docker

Image and Video hosting software

v4-docs.chevereto.com

I did not manually change the database image or Docker configuration before the upgrade.

My original 4.4.2 installation was running with the official mariadb:jammy database container.

After following the official upgrade procedure to 4.5, the database container could no longer start and reported:

[ERROR] [InnoDB] Tablespace flags are invalid in datafile: ./ibdata1
[ERROR] [InnoDB] Corrupted page [page id: space=0, page number=0]
[ERROR] [InnoDB] Plugin initialization aborted with error Data structure corruption.
[ERROR] [Server] Failed to initialize DD Storage Engine
[ERROR] [Server] Data Dictionary initialization failed.
[ERROR] [Server] Aborting

After investigating the Git history, I noticed that the official Docker configuration was recently changed from:

image: mariadb:jammy
to:

image: mysql:8 #evergreen
This appears in the update compose commit (feb0f01).

The existing database Docker volume from my Chevereto 4.4.2 installation was created by MariaDB. After upgrading to 4.5, the new MySQL 8 container appears to mount the same existing /var/lib/mysql volume.

This seems to be why MySQL 8 reports the existing MariaDB ibdata1 as invalid/corrupted.

Fortunately, I made a .sql.gz database backup before starting the upgrade.

I then tried using a fresh MySQL 8 database and restoring that backup with the official Makefile command:

make database-restore
However, the restore also fails:

mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 3105 (HY000) at line 430: The value specified for generated column 'image_type' in table 'chv_images' is not allowed.
make: *** [Makefile:308: database-restore] Error 1
The backup contains this column in chv_images:

image_type tinyint(3) unsigned GENERATED ALWAYS AS (
case
when image_extension in ('pdf','doc','md') then 4
when image_extension in ('mp3','m4a','wav') then 3
when image_extension in ('mp4','webm','mov') then 2
when image_extension in ('avif','jpg','jpeg','gif','png','webp') then 1
else 0
end
) STORED
The MariaDB dump uses:

INSERT INTO chv_images VALUES (...);
so the dump includes the stored value for image_type. MySQL 8 rejects this during import because image_type is a generated column.

Could you please advise what the official migration procedure from Chevereto 4.4.2 to 4.5 is for existing Docker installations?

In particular:

1. Is the MariaDB → MySQL 8 migration supposed to be handled automatically when following the official 4.4.2 → 4.5 upgrade procedure?
2. Is the existing MariaDB Docker volume expected to work with the new MySQL 8 container, or should a new MySQL volume be created?
3. What is the recommended way to migrate the Chevereto 4.4.2 MariaDB database to MySQL 8?
4. How should a .sql.gz backup from the previous official MariaDB setup be restored into the new MySQL 8 setup when generated columns cause ERROR 3105?
5. Should I revert to the 4.4.2/MariaDB environment first, restore the database there, and then perform a separate MariaDB → MySQL migration?

I still have my original database backup, so the data is safe. I would prefer to follow the officially supported 4.4.2 → 4.5 migration procedure rather than manually modifying the SQL dump.

Any guidance would be appreciated. Thanks!

 

[Rodolfo]

Hello,

The DOCKER-COMPOSE.md file explicitly remarks this change:

Note: For legacy setups use default-mariadb.yml (MariaDB) as the default compose file. This can be achieved by adding COMPOSE=default-mariadb in your project namespace file.

You need to modify your namespace file, to explicitly indicate the default-mariadb compose file:

COMPOSE=default-mariadb

Some background on this: For several years back to the MySQL 5 and early 8, MariaDB was marketed as a 1:1 replacement for MySQL (they anchored the pun drop-in replacement) but in reality MySQL and MariaDB are not longer compatible for database restore/backup at all, that compatibility has vanished and there's no easy way to migrate from one to another.