Cloning an app to same server after migrating from MySQL to MariaDB

If you have questions or if you want to share your opinion about Aware IM post your message on this forum
Post Reply
MESSI
Posts: 14
Joined: Thu Dec 29, 2022 11:09 pm

Cloning an app to same server after migrating from MySQL to MariaDB

Post by MESSI »

Hello,

Recently I have migrated from MySQL 5.6 to MariaDB 10.9. So far, so good.

Now I'm trying to clone an BSV on same server

1. Backup DB with DBtool to a SQL file
2. Create New BSV
3. Import DB with DB tool from #1 sql file created.

I get this error
Screenshot_448.jpg
Screenshot_448.jpg (44.8 KiB) Viewed 3367 times

Code: Select all

Error (953,1): Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current
row format, BLOB prefix of 768 bytes is stored inline.
Any help would much appreciated.
AwareIM 8.5, 8.7 - MySQL, MariaDB
Jaymer
Posts: 2430
Joined: Tue Jan 13, 2015 10:58 am
Location: Tampa, FL
Contact:

Re: Cloning an app to same server after migrating from MySQL to MariaDB

Post by Jaymer »

I must be missing something.
Normally this is done inside the Config Tool... export and import a BSV? No?
Click Here to see a collection of my tips & hacks on this forum. Or search for "JaymerTip" in the search bar at the top.

Jaymer
Aware Programming & Consulting - Tampa FL
MESSI
Posts: 14
Joined: Thu Dec 29, 2022 11:09 pm

Re: Cloning an app to same server after migrating from MySQL to MariaDB

Post by MESSI »

Thank you for your reply.

I missed something:
2.b. Export the old BSV
2.c. Import the BSV into the new created one.

I want to have not only the BSV cloned, but also the entire DB with all data.
AwareIM 8.5, 8.7 - MySQL, MariaDB
PointsWell
Posts: 1457
Joined: Tue Jan 24, 2017 5:51 am
Location: 'Stralya

Re: Cloning an app to same server after migrating from MySQL to MariaDB

Post by PointsWell »

There's insufficient information in this to help.

At a guess there is a mismatch between the limitations between MySQL and MariaDB. Whatever tool you are using should have more detailed import logs that indicate which row the import is failing on. That will help you locate the record and then you can investigate the sizes of the records.
customaware
Posts: 2391
Joined: Mon Jul 02, 2012 12:24 am
Location: Ulaanbaatar, Mongolia

Re: Cloning an app to same server after migrating from MySQL to MariaDB

Post by customaware »

Use the ESF Database Migration Toolkit

I use it all the time and it is brilliant.


https://www.dbsofts.com
Cheers,
Mark
_________________
AwareIM 6.0, 8.7, 8.8, 9.0 , MariaDB, Windows 10, Ubuntu Linux. Theme: Default, Browser: Arc
Upcloud, Obsidian....
Image
ACDC
Posts: 1138
Joined: Sat Jun 30, 2007 5:03 pm
Location: California, USA

Re: Cloning an app to same server after migrating from MySQL to MariaDB

Post by ACDC »

or just ask ChatGPT :D

The error message you received indicates that the row size in your database table is too large. In MySQL, the maximum row size is 65,535 bytes. The specific error message you provided suggests that the row size exceeds this limit (8126 bytes).

To resolve this issue, you can consider the following options:

Change column types: If your table contains columns with large data sizes, such as VARCHAR or TEXT, you can consider changing them to the TEXT or BLOB types. These types store the actual data separately and store a reference in the row, which can help reduce the row size.

Modify the row format: You can change the row format to either DYNAMIC or COMPRESSED. These row formats can help optimize the storage of large columns, allowing more data to be stored within the row size limit.

To change the row format to DYNAMIC, you can execute the following SQL statement before creating or altering your table:

sql

ALTER TABLE your_table_name ROW_FORMAT=DYNAMIC;

To change the row format to COMPRESSED, you can execute the following SQL statement:

sql

ALTER TABLE your_table_name ROW_FORMAT=COMPRESSED;

It's important to note that changing the row format may have implications on the performance and storage requirements of your table, so it's advisable to test and benchmark the changes in a development environment before applying them in production.

Remember to backup your database before making any significant changes to your table structure or row format.
Post Reply