As I wrote in the previous LRU followup the innodb_lru_dump_restore directive has the drawback that it only loads the LRU dumpfile after starting up. I’m happy to say that I’m not the only one who noticed that: Vadim Tkachenko noticed the same a few months back when he was integrating Galera replication and he filed a bugreport for it.

It now has been resolved as of Percona Server 5.1.59-13.0 and 5.5.16-22.0 (both released this morning) with the configuration directive innodb-blocking-lru-restore.

However

Due to one of the machines being configured a little bit too close to the edge we had to restart it to downsize its innodb_buffer_pool_size a little bit. We tested the innodb_lru_dump_restore directive with this machine. Results were very promising: it wrote the dump every 5 minutes (we set the variable to 300 seconds) and after MySQL had restarted it reloaded the dump.

However: since MySQL is already started fully before it even starts to load the LRU dump it means MySQL is already available to the outside world. This means in a HA environment it would already be going to perform poorly due to the torrent of queries coming in. This means either the loading of the LRU dump needs to be done up front by a change in Percona Server or we need to alter MMM not to do anything with the server untill it has loaded the LRU dump.

Challenges, challenges…

Yesterday one of my colleagues pointed me to the innodb_lru_dump_restore variable available in the Percona MySQL Server distribution. See more about it here:
innodb_lru_dump_restore
LRU meaning that the list is in Least Recently Used order to make it easier to remove old items off the pages. Reading from the description it can be a very nice option for already running servers to maintain this list after startup, but it did not solve my immediate problem: I had to warm up two new freshly cloned read slaves on one of our busiest databases.

Normally I use mk-query-digest with the