MyISAM to InnoDB

I was recently working on an all cloud/PaaS solution leveraging Azure AKS, Azure File, and Azure MySQL. After learning the hard way on several components, I was able to create a fairly clean environment, however, when it came time to connect to MySQL, I noticed that Azure does not support the MyISAM engine. In fact, it seems that none of the cloud providers support MyISAM due to “the lack of transaction support which can lead to cases of data loss.” With that said, I am curious if anyone is aware of any potential issues with converting to the InnoDB engine or if done, what impacts that could lead to? Obviously we can move to a dedicated MySQL server, but were trying to stick with PaaS solutions.


Hi Drew, welcome to the Gibbon forums :smiley:

This is a change we’ve been looking into as well for the core, as you mention transaction support can be very important and not available with MyISAM. I think the key will be to find the safest way to include this kind of change into the update process (particularly because of the current lack of transaction support to rollback if there’s any problems or timeout).

So-far @UrkoM and myself have tested switching to InnoDB on our systems and haven’t encountered any potential issues or impacts. The one notable change is that InnoDB doesn’t support fulltext indexing, however it’s a pretty minor drawback and currently only used in two places in the Library module.

If you’re interested in helping test the process and making the switch so that you can run on Azure, I’ve attached an SQL file which when run on a Gibbon database will change each table over to InnoDB, including dropping the two indexes. On a moderately sized db this can take a moment to run. Be sure to backup your entire database before running it, and of you have an install setup for testing it’s best to run it on that first too.

Hope this helps! Give a shout if you do make the switch, I’d be keen to hear how it goes.

Hi Drew,

Looks like Sandra’s got you covered here. Thanks for prompting us on this: it is long overdue, but not something to change lightly.

I’ve made the switch on my development environment, and will keep an eye on it over the coming weeks. Let us know how you get on.

Incidentally, when I made the switch I ran into a database specification error, which is fixed in this commit to v16:

In the meantime, if you’ve got any additional modules installed, then the PHP file attached dynamically generates the conversion codes, to include all tables in the database. The commands still need to be run manually in a client…was not sure I wanted to automate to that level at this early stage!



I will work on this during the week. I spun up a Linux vm with MySQL and will run the scripts on it, back it up, and then restore on azure MySQL. In the current phase, we are not looking at the library module, so I think we are ok on that one. Thanks for the help!