Author Archives: Rich Prohaska

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: , ,

Interactive Debugging of Transaction Conflicts with TokuDB

Posted On October 16, 2013 | By Rich Prohaska | 4 comments

I am developing a concurrent application that uses TokuDB to store its database. Sometimes, one of my SQL statements returns with a ‘lock wait timeout exceeded’ error. How do I identify the cause of this error? First, I need to understand a little bit about how TokuDB transactions use locks. Then, I need to understand […]

Tagged: ,

A TokuDB Stall Caused by Conflicting Transactions When Opening a Table

Posted On October 3, 2013 | By Rich Prohaska | 0 comments

One of our customers reported that ‘create table select from’ statements stall for a period of time equal to the TokuDB lock timeout.  This indicated a lock conflict between multiple transactions.  In addition, other MySQL clients that were opening unrelated tables were also stalled.  This indicated that some shared mutex is held too long.  We […]

Tagged: , , , ,

A TokuDB Stall Caused by a Big Transaction and How It was Fixed

Posted On September 20, 2013 | By Rich Prohaska | 2 comments

One of our customers sometimes observed lots of simple insertions taking far longer than expected to complete. Usually these insertions completed in milliseconds, but the insertions sometimes were taking hundreds of seconds. These stalls indicated the existence of a serialization bug in the Fractal Tree index software, so the hunt was on. We found that […]

Tagged: , , , ,