[MySQL] Omzetten veel data van MyISAM naar InnoDB

[cyberstalker]

Ik ben bezig om op een aantal MySQL servers alle tabellen van MyISAM om te zetten naar InnoDB. Het gaat om totaal ongeveer 3 TB aan data, waarbij individuele tabellen soms 20 tot 30 GB zijn. Deze data staat verdeeld over meerdere servers, die al hun data opslaan op een SAN.

Om overlast voor gebruikers te minimaliseren gebruik ik een van onze backup servers, cloon ik daarop het volume van een andere server en draai ik hierop de conversie. Hierbij bleek echter dan onze SAN met normale load al erg zwaar belast is, en deze extra load niet goed blijkt te trekken.

Nu heb ik bedacht om voor het starten van de conversie individuele databases naar de lokale schijf te kopieren, een symlink naar deze directory te maken en de data na de conversie weer terug te zetten. Dit kan onze SAN veel beter aan, omdat hiermee de IO voornamelijk sequentieel wordt. MySQL is geconfigureerd met innodb_file_per_table = 1, dus de .ibd bestanden worden in de directory op het lokale bestandssysteem aangemaakt.

Daarnaast heb ik ook de ibdata en ib_logfile* verplaatst naar een directory gemount op tmpfs en gesymlinkt. Ik zie nu tijdens het alteren van de tabellen nauwelijks activiteit naar de SAN (waarmee enige overlast voor klanten dus wordt beperkt).

Nu zie ik dat het converteren van een 10 GB tabel ongeveer twee uur duurt. Dat zou mijns inziens wel sneller moeten kunnen. Als ik met iotop kijk zie ik dat er ongeveer 50% IO wait is. IO lijkt dus niet de bottleneck. Geen van de CPU's zit op 100% tijdens de conversie (1 van de 32 zit ongeveer op 30%). Ook is er ruim voldoende RAM aanwezig (ongeveer 50 van de 64 GB vrij).

Wat zou ik nog kunnen doen om dit proces te versnellen?

[CAPSLOCK2000]

Hoe doe je die conversie precies? Als je het op een draaiende database doet kan ik me voorstellen dat hij veel tijd bezig is met wachten op locks en het controleren van constraints. Misschien dat het sneller gaat als je de hele database dumpt en opnieuw importeert.
MySQL is out-of-the-box nogal conservatief geconfigureerd. Misschien moet je de configuratie aanpassen om meer RAM/CPU te gebruiken.

[jnr24]

Heb je het met een mysqldump export en import gedaan? Dat lijkt me redelijk sequentieel en er zitten ook

SET foreign_key_checks = 0;

statements in die allerlei complexe constraints voorkomen tijdens het laden.