EmergencyEMERGENCY? Get 24/7 Help Now!

Recovery Time for TokuDB

 | December 16, 2009 |  Posted In: Tokutek, TokuView


Last week Tokutek released version 3.0.0 of TokuDB, adding ACID transactions to its list of features. This post discusses an experiment we ran to measure recovery time following a system crash.

In summary, while actively inserting records into a MySQL database using iiBench, we compared the time to recover from a power-cord pull for both InnoDB and TokuDB.

Storage Engine Recovery Time
TokuDB 501s (8 min, 21 sec)
InnoDB 18505s (5 hours, 8 min, 25 sec)

This is by no means an exhaustive look at recovery performance, but does illustrate the benefits of Tokutek’s approach.

The experiment

We ran iiBench on the following server:

The disks and RAID controller were configured with the write-caches OFF using arcconf. (Note: an experiment with the RAID controller write-cache ON resulted in a non-recoverable database, as you should expect)

We ran an insert-only iiBench test. After inserting about 250M rows and while actively inserting more, we manually pulled the plugs (2 on a Sunfire x4150). We then powered up the server and timed how long it took to start mysqld.

The results for InnoDB are not surprising – they are in line with results reported elsewhere. During recovery, InnoDB reported 1 transaction to be rolled back or cleaned up, and 68 row operations to undo.

The results for TokuDB are encouraging, in that they indicate recovery can be performed in minutes instead of hours. In this experiment, rebooting the server almost took as long as recovering the TokuDB database.

The primary reason for TokuDB’s quick recovery time is the use of regular, automatic checkpoints. This feature (introduced in version 2.0.0) ensures that work is completed and written to disk (including the necessary fsync) on a regular basis. Recovery is limited to processing uncommitted transactions and work since the last checkpoint. When not pushing performance to the absolute max we find recovery times typically take less than a minute.



  • oh come on, everyone knows that InnoDB has two low hanging fruits, that are relatively small patches, which would make recovery as fast as TokuDB’s.

    See http://mituzas.lt/2009/12/08/crash-recovery-again/ for example 🙂

    • Domas – thanks for the pointer. You are correct. I re-ran the experiment, and it only took 1020s to recover with your patched version. Do you have any idea when these changes will be rolled into the standard product?

Leave a Reply


Percona’s widely read Percona Data Performance blog highlights our expertise in enterprise-class software, support, consulting and managed services solutions for both MySQL® and MongoDB® across traditional and cloud-based platforms. The decades of experience represented by our consultants is found daily in numerous and relevant blog posts.

Besides specific database help, the blog also provides notices on upcoming events and webinars.
Want to get weekly updates listing the latest blog posts? Subscribe to our blog now! Submit your email address below and we’ll send you an update every Friday at 1pm ET.

No, thank you. Please do not ask me again.