Author Archives: Rich Prohaska

TokuDB Hot Backup Now a MySQL Plugin

Posted On February 5, 2015 | By Rich Prohaska | 2 comments

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 […]

Tagged: , , ,

TokuDB 7.5.5 is now available

Posted On January 29, 2015 | By Rich Prohaska | 0 comments

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 […]

Tagged:

Scaling TokuDB Performance with Binlog Group Commit

Posted On December 17, 2014 | By Rich Prohaska | 3 comments

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 commits […]

Tagged: , , , ,

An Updated Description of Clustering Keys for TokuDB

Posted On August 6, 2014 | By Rich Prohaska | 0 comments

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 on […]

Tagged: , , , , ,

Why TokuDB does not use the ‘uint3korr’ function

Posted On April 8, 2014 | By Rich Prohaska | 0 comments

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: Attention: […]

Tagged: , ,

Uninitialized data in the TokuDB recovery log

Posted On April 3, 2014 | By Rich Prohaska | 0 comments

A TokuDB MySQL test run with valgrind reported an uninitialized data error when writing into the TokuDB recovery log. ==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) […]

Tagged: , ,

Lock Escalation and Big Transactions in TokuDB and TokuMX

Posted On March 27, 2014 | By Rich Prohaska | 0 comments

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 […]

Tagged: ,

Big trouble with zero-length character columns in TokuDB

Posted On March 17, 2014 | By Rich Prohaska | 0 comments

What good is a zero-length character column in a MySQL table? A zero-length character column has type of ‘char(0)’. If it is nullable, then it can at least store one bit. If it is not nullable, then the value for this column in all rows is a null string. IMO, not very useful. However, the […]

Tagged: ,

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

Posted On November 19, 2013 | By Rich Prohaska | 0 comments

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 […]

Tagged: , ,

Problems with Multiple XA Storage Engines in MySQL 5.6

Posted On October 23, 2013 | By Rich Prohaska | 1 comments

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 the […]

Tagged: , ,