CODEWITHSUNDEEP
mysqldatabasedrupal-7innodbmyisam
MiBerG
MiBerG

Reputation: 35

What are the consequences of converting the storage engine of a MySQL database from InnoDB to MyISAM and back (Drupal 7 specific)?

I'm in the process of upgrading a medium scale (200k+ users) Drupal 6 CMS to Drupal 7. Data migration will be handled by using the Migrate Module. Up to and including Drupal version 6, MyISAM was the default MySQL storage engine for the Drupal database. Since Drupal version 7, InnoDB is recommended. According to this, the migration classes I've developed have to migrate data from the old D6 MyISAM DB to the new D7 InnoDB DB.

I'm experiencing serious performance issues when I run the migration scripts: The migration of the 200k+ user profiles would take more than 20 hours on a "large" Amazon Web Services server instance, which has actually been optimized for this purpose. Such performance issues are not uncommon for migrations utilizing said migration module, as I've learned from reading the module's issues tracker. However, I've found a solution to increase the performance tenfold by converting the D7 DB from InnoDB to MyISAM.

Now here's the question: Since I'll have to run the D7 DB using the InnoDB storage engine once it will be used by the users again, I wonder whether it could mean any harm to the DB if I set the storage engine to MyISAM for the duration of the migration process and afterwards back to InnoDB?

Thanks for your help.

Upvotes: 1

Views: 1112

Answers (2)

user2656474
user2656474

Reputation: 81

you can also change sync_binlog variable to 0 ant it can also increase the speed upto 20% and after migration you can set it back to 1.

but in between if there would be some power failure in between the process, you might lose some data. but i think you are just migrating the data, then it will not take so much time and chances of power failure are very low.

Upvotes: 0

jeremycole
jeremycole

Reputation: 2761

If you're seeing a very large performance difference between InnoDB and MyISAM, it's very likely that the reason is due to transactional guarantees that InnoDB is making. Setting the innodb_flush_log_at_trx_commit variable to 0 during migration should allow you to achieve very good performance for the time of the migration, and you can then set it back to 1 after migration has completed.

It is safe to change on-the-fly; however you should note that if the server crashes while it is set to 0, you may lose some committed transactions (but for your migration I'd guess that caveat is fine).

Upvotes: 4

Related Questions