I just came across a particular feature of MySQL while using inspecting a Query Cache being wiped out at backup times. Whenever you run FLUSH TABLES, the whole Query Cache gets flushed as well, even if you FLUSH TABLES a particular table. And guess what,
mysqlhotcopy issues FLUSH TABLES so the tables get in sync on storage.
I actually noticed the problem with Query Cache on a server reporting the cache flush at a [too] round time (backup time).
First thought was «there’s something wrong about
mysqlhotcopy. But actually this is expected behaviour:
When no tables are named, closes all open tables, forces all tables in use to be closed, and flushes the query cache. With one or more table names, flushes only the given tables. FLUSH TABLES also removes all query results from the query cache, like the RESET QUERY CACHE statement.
I got curious about why the heck closing a table should invalidate the cache - maybe the “close table” mechanism is overly cautious?
Anyway, it’s not
mysqlhotcopy’s fault. And since you should issue FLUSH TABLES for LVM snapshost for consistentency as well, this method is also affected, which renders both methods pretty counter-perfomance in a single production server, comparing to
mysqldump, unless you do post-backup warmup process. For that, it would be interesting to be able to dump the QC contents and reload them after the backup - which is not possible, at the moment… bummer…