Question

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.

Answer 1

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).