Welcome to Datavail’s Blog, where you can read the latest insights, tips and opinions of our experts on all things data and technology.
If you frequently delete rows (or update rows with variable-length data types), you can end up with a lot of wasted space in your data file(s), similar to filesystem fragmentation. If you’re not using the innodb_file_per_table option, the only thing you can do about it is export and import the database, a time-and-disk-intensive procedure.
Sometimes you find yourself in a bad situation where your only hope of recovering your InnoDB data lies in a handful of .frm and .ibd data files that were heretofore part of a working MySQL installation. It could be the case that someone thought backing up InnoDB tables was simply a matter of of copying the .ibd and .frm files somewhere safe.
If you’re using MySQL replication, chances are your master and slave databases aren’t entirely consistent. There are a number of reasons for this. Some MySQL functions like UUID() don’t replicate properly with statement based replication. Poor network connectivity can sometimes result in corrupted relay logs. Misconfigured software can accidently write to the slave database.