In case you missed it, MySQL Utilities 1.3.0 (alpha) was released last week. MySQL Utilities is a component of MySQL Workbench, but it’s been broken out into a separate download allowing command-line users access unencumbered by a pretty GUI interface. Plus, it has some new features – most importantly to me, a utility (mysqlfrm) which can read .FRM files and produce CREATE TABLE statements as a result. This will be very useful for recovery processes, in conjunction with InnoDB transportable tablespaces in situations where the InnoDB system tablespace is corrupted, and you don’t know the exact table definition.
When we first started testing the FRM reader, it didn’t bootstrap mysqld to decipher .FRM file contents – Chuck Bell spent hours staring into the abyss that is FRM file formats and trying to shed light in the many dark corners that exist. We started with simple tests, like: can it read all the .FRM files in the data/mysql directory? Then I hacked a quick program that created tables with many different data types, modifiers and variants. But these tests were all dwarfed by the contribution of my colleague and bug-finder extraordinaire, Shane Bester, who gave us what may well be the world’s ugliest table. Behold:
Continue reading MySQL Utilities meets the world’s ugliest table
I’ve noted previously that the new transportable tablespaces for InnoDB in MySQL 5.6 are a big step forward, and newly-released 5.6.9-rc makes importing tablespaces a bit easier. In previous versions, you had to have a .cfg file to import the InnoDB tablespace. That file is produced during FLUSH TABLE <tbl> FOR EXPORT operations, and contains InnoDB metadata that’s not contained in the .ibd tablespace file itself. I filed a feature request requesting the .cfg file be made optional, and Sunny implemented it: Continue reading Smarter InnoDB transportable tablespace management operations
If you’re anything like me, your initial reaction upon hearing about transportable tablespaces for InnoDB in 5.6 was to imagine it like MyISAM, where you can copy the .frm, .myi and .myd files around to your heart’s content, and everything will be great. You might have read Sunny’s excellent blog, and realized that there’s a bit more to it than that – you have to explicitly prepare the tablespace for copying using FLUSH TABLES FOR EXPORT. That’s perfectly acceptable for the bulk of use cases, such as single-table InnoDB backups, and opens up exciting new possibilities for moving or copying InnoDB data at the filesystem level.
But for situations where the need is a little different, you might really dug into it and start to wonder about the .cfg files produced during the FLUSH TABLES FOR EXPORT operation. What happens if you don’t have – and can’t produce – that information? What does that .cfg file contain that makes it critical to success importing the tablespace later? Continue reading Understanding InnoDB transportable tablespaces in MySQL 5.6