//
archives

LRU Dump

This tag is associated with 3 posts

LRU followup #2

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 the bugreport states there are two different directived: innodb-blocking-lru-restore (5.1) and innodb-blocking-buffer-pool-restore (5.5). Just tested it on our test machine and the latter is the correct directive and probably the release notes of the 5.5 release were copied from the 5.1 release. I’ve just commented this in the 5.5 release post, so I think it will be corrected soon.

The directive works as it should: during the InnoDB initialization it loads the LRU dump:

mysqld: 111017 10:13:12 InnoDB: Completed initialization of buffer pool
mysqld: 111017 10:13:12 InnoDB: highest supported file format is Barracuda.
mysqld: 111017 10:13:12 InnoDB: Restoring buffer pool pages from ib_lru_dump
mysqld: 111017 10:13:12 InnoDB: Waiting for the background threads to start

Works like a charm and I’m very happy with this change. :)
Of course the LRU dump of our test machine is very small (512MB bufferpool) so it was loaded instantly. On a normal machine it should take a bit longer…

LRU follow up

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…

LRU Dump restore

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 –processlist option on the (active) master, but in our setup this is seriously flawed because Continue reading

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 427 other followers

Follow

Get every new post delivered to your Inbox.

Join 427 other followers