Hello,

> key_buffer = 1G
> innodb_file_per_table
> innodb_flush_method=O_DIRECT
> innodb_flush_log_at_trx_commit=2
> innodb_buffer_pool_size=12G
> innodb_log_buffer_size=4M
> innodb_thread_concurrency=8

You can tune innodb_log_file_size. Beware, you have to shut mysql down 
correctly and move redo files to recreate new ones.

What is the format of the tables ? COMPRESSED ? COMPACT ? (you can see 
it in INFORMATION_SCHEMA)

> We'll now do some further testing to see if dump speed has improved
> and how writing during backups and volume expiry performs.

Dumping a table is fast. Reimporting it is VERY slow.
For big databases, I use mylvmbackup to perform LVM snapshots.

> The File table space has grown from 160GB in MyISAM to a whopping
> 294GB on InnoDB, what could be the reason for this apart from the
> indices now being stored within the IBD file? Index size was around
> 40G on MyISAM before.

InnoDB needs more space by design.

Space freed in the table is never freed on filesystem. I advise you to 
run dbcheck periodically to control the database's size.

> I hope you find this information useful in planning / sizing your own
> myisam -> innodb migration if you haven't already done so. I'd also 
> be
> grateful if you'd point out any obvious flaws or improvments to the
> settings noted above. I wonder if dumping the file table and then
> re-importing it to an innodb replacement would have been quicker? 
> Time
> for more testing I guess ;)

Usually, it's faster to dump / reimport.
It would anyway took dozens of hours...

Hope this helps.
Jerome Blion.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users