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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
