• Plesk Uservoice will be deprecated by October. Moving forward, all product feature requests and improvement suggestions will be managed through our new platform Plesk Productboard.
    To continue sharing your ideas and feedback, please visit features.plesk.com

Forwarded to devs Migrate fails for database, when a table have ROW_FORMAT=FIXED

Azurel

Silver Pleskian
User name: Azurel

TITLE

Migrate fails for database, when a table have ROW_FORMAT=FIXED

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

CentOS 8.2, Plesk Obsididan 18.0.29#1

PROBLEM DESCRIPTION

I tried to migrate from CentOS 7.8 (MariaDB 10.1.45) to CentOS 8.2 (MariaDB 10.3.17) and get a error.
I make daily backup (mysqldump) for this database (and import localhost on pc), without ever have a error. What could be the problem here? After import my mysqldump on pc(windows 10) this table is automatically ROW_FORMAT=DYNAMIC

Failed to copy content of database 'mydomain1'
Migration tools tried to perform operation in 3 attempts: Command execution failed on the local server with non-zero exit code.
command: mysql --defaults-file=/usr/local/psa/var/modules/panel-migrator/sessions/20200807122600/target-server/my_localhost_mydomain1.cnf -h localhost -P 3306 -uadmin mydomain1 < /usr/local/psa/var/modules/panel-migrator/sessions/20200807122600/target-server/db-dumps/mydomain1.sql
exit code: 1
stdout:
stderr: ERROR 1005 (HY000) at line 10887: Can't create table `mydomain1`.`sessions` (errno: 140 "Wrong create options")

The plesk export should maybe use something like this?
cat mysqldump | sed -r 's/ROW_FORMAT\s*\=\s*FIXED/ROW_FORMAT=DYNAMIC/g' > output.sql

I have fixed it in source database with set
ALTER TABLE `sessions` ROW_FORMAT=DEFAULT;
After that, migration working fine.

STEPS TO REPRODUCE

Migrate database from server1 to server2 with table that set as ROW_FORMAT=FIXED

ACTUAL RESULT

see description

EXPECTED RESULT

no errors

ANY ADDITIONAL INFORMATION



YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
Thank you,
The bug PMT-4814 has been confirmed.
Another workaround is to set innodb_strict_mode=0 for the target DB server.
 
Back
Top