Author - Rich.Prohaska

TokuDB Hot Backup Now a MySQL Plugin

In the recently released TokuDB 7.5.5 the implementation of TokuDB hot-backup moved from a patch to the MySQL Server, to MySQL Plugin.  Why did we make this change?
TokuDB hot backup makes a transactionally consistent copy of the TokuDB files while applications continue to read and write these files.  Christian Rober wrote a nice series […]

Read more

TokuDB 7.5.5 is now available

Tokutek is pleased to announce the general availability of TokuDB 7.5.5. The notable changes since TokuDB 7.5.3 are:

Rebased onto MySQL 5.5.41 and MariaDB 5.5.41 to integrate the latest changes
Improved TokuDB lock timeout logging
Added several optimize table options for TokuDB tables including the ability to throttle the optimize operation, selectively pick indexes to optimize, optimize a percentage […]

Read more

Scaling TokuDB Performance with Binlog Group Commit

TokuDB offers high throughput for write intensive applications, and the throughput scales with the number of concurrent clients.  However, when the binary log is turned on, TokuDB 7.5.2 throughput suffers.  The throughput scaling problem is caused by a poor interaction between the binary log group commit algorithm in MySQL 5.6 and the way TokuDB […]

Read more

An Updated Description of Clustering Keys for TokuDB

Covering indexes can result in orders of magnitude performance improvements for queries. Bradley’s presentation on covering indexes describes what a covering index is, how it can effect performance, and why it works. However, the definition of a covering index can get cumbersome since MySQL limits the number of columns in a key to 16 (32 […]

Read more

Why TokuDB does not use the ‘uint3korr’ function

The ‘uint3korr’ function inside of the mysqld server extracts a 3 byte unsigned integer from a memory buffer. One use is for ‘mediumint’ columns which encode their value in 3 bytes. MySQL 5.6 and MariaDB 10.0 claims to have optimized this function for x86 and x86_64 processors. There is a big comment that says:

Shell

Attention: […]

Read more

Uninitialized data in the TokuDB recovery log

A TokuDB MySQL test run with valgrind reported an uninitialized data error when writing into the TokuDB recovery log.

Shell

==1032== Syscall param write(buf) points to uninitialised byte(s)
==1032== at 0x3EFA60E4ED: ??? (in /lib64/libpthread-2.12.so)
==1032== by 0xB894038: toku_os_full_write(int, void const*, unsigned long) (file.cc:249)
==1032== by 0xB83248A: write_outbuf_to_logfile(tokulogger*, __toku_lsn*) (logger.cc:513)
==1032== by 0xB83326C: toku_logger_maybe_fsync(tokulogger*, __toku_lsn, int, bool) (logger.cc:836)
==1032== by 0xB8327DE: toku_logger_fsync_if_lsn_not_fsynced(tokulogger*, […]

Read more

Lock Escalation and Big Transactions in TokuDB and TokuMX

We have seen TokuDB lock escalation stall the execution of SQL operations for tens of seconds. To address this problem, we changed the lock escalation algorithm used by TokuDB and TokuMX so that the cost of lock escalation only affects big transactions. We also eliminated a serialization point when running lock escalation.
Transactions in TokuDB […]

Read more

What does the ‘Incorrect key file for table’ error mean?

What does it mean if MySQL returns the ‘Incorrect key file for table’ error for one of my queries? The answer is complicated and depends on which storage engine is returning the error. We have debugged two cases which we describe here.
File system out of space
When running the random query generator, one of the […]

Read more

Problems with Multiple XA Storage Engines in MySQL 5.6

While integrating TokuDB into MySQL 5.6, we found that MySQL 5.6 does not support more than one XA storage engine. For example, there is an assert in the ha_recover function that fires when the total number of XA storage engines is greater than one. After disabling this assert, we found lots of bugs in […]

Read more