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 queries failed.

Query: SELECT * FROM (mysql . general_log AS table1 INNER JOIN INFORMATION_SCHEMA . INNODB_BUFFER_PAGE AS table2 
ON ( table2 . SPACE = table1 . user_host ) ) ORDER BY table1 . thread_id LIMIT 168 
failed: 126 Incorrect key file for table '/data/mysql7/performance_schema_vardir/tmp/#sql_6b8_17.MYI'; 
try to repair it

Since this query requires a sort, MySQL creates a hidden temporary table called ‘#sql_6b8_17.MYI’ to hold the intermediate results. While the query was executing, some operation performed on the MyISAM table returned an error. What could it be?

MySQL maps the …

Today before Ivan’s tutorial, he told me that in the 10.0.5 virtual machine images he created, he couldn’t find the Cassandra storage engine. I told him it had to be installed separately, and this is true – you have to install some engines separately!

When you do a yum install MariaDB-server MariaDB-client like the installation instructions tell you to do, you don’t get all storage engines (so running SHOW ENGINES might have you wondering what happened to a bunch of engines). This can easily be seen by doing a yum search MariaDB. On a CentOS 6.4 server with the MariaDB 10.0 repository configured, you should see the following:

MariaDB-cassandra-engine.x86_64 : MariaDB: a very fast and robust SQL database server
MariaDB-client.x86_64 : MariaDB: a very fast and robust SQL database server
MariaDB-common.x86_64 : MariaDB: a very fast and robust SQL …

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 MySQL 5.6 implementation of the TC_LOG_MMAP class, which is used when running with the binlog turned off.

There are two alternatives that we know of to fix this problem in MySQL 5.6:

• First, we could merge code from MariaDB 5.5 into MySQL 5.6. The advantage of this approach is that we have been running this code with TokuDB in MariaDB 5.5 for a long time, so we have confidence in its correctness.
• Second, we found that MySQL 5.7.2 has made changes to allow multiple XA storage engines. This is great news for TokuDB since we have one less MySQL patch to worry about. Our simple scan of the MySQL 5.7 source showed …

Save Time & Money – Do It Right The First Time

SPEAKER: Gerry Narvaja, Tokutek
DATE: Tuesday, October 8th
TIME: 1pm ET

If you are thinking of using the leading open source database in a project, learn just how easy it is to get started with MySQL, and how important it is to do it right. A few simple decisions early in development, and knowing when and how to effectively use the TokuDB performance engine, can save significant time and money down the road. Key metrics for MySQL success include performance, scalability, database size, and agility. Register Now!

Attend this webinar to learn:

• The basics of installing and configuring MySQL and TokuDB
• How to maximize performance for long-term scalability
• How to configure compression for highest ROI
…

One thing you might have missed from the MariaDB 10.0.4 Alpha release announcement is that SPIDER is finally in-tree, inside MariaDB. I’ve been watching the SPIDER engine for quite some years and fondly remember the time when Kentoku Shiba dressed up as spiderman at a MySQL Conference.

There are many factors that plays to an engines success. Distribution is one of them. Having a company backing it with services is another, so it is with great pleasure that I also show you Spiral Arms Ltd by Kentoku and Goto.

Overall, a good time to celebrate and I’m very happy for Kentoku and Goto. Now to promote its use. …

Recently, we’ve seen a few people ask us about building TokuMX from scratch. While it’s best if you just use the binaries you can get from us (they have all the right optimizations, we’ve tested them, and we can interpret coredumps they generate), we recognize there are other reasons you might need to do a custom build.

Since we actually build six distinct products all using the Fractal Tree indexing® library (community and enterprise versions of TokuDB for MySQL, TokuDB for MariaDB, and TokuMX), our build process is pretty complicated, compared to software packages that might, for example, just involve one source repository and link against a few standard libraries. Our TokuMX builds involve four git repositories, three separate build stages, two different build tools, and …

A lot is said about the differences in the data between MySQL and MongoDB. Things such as “MongoDB is document based”, “MySQL is relational”, “InnoDB has a clustering key”, etc.. Some may wonder how TokuDB, our MySQL storage engine, and TokuMX, our MongoDB product, fit in with these data layouts. I could not find anything describing the differences with a simple google search, so I figured I’d write a post explaining how things compare.

So who are the players here? With MySQL, users are likely familiar with two storage engines: MyISAM, the original default up until …

In my last post, I showed what a Fractal Tree® index is at a high level. Once again, the Fractal Tree index is the data structure inside TokuMX and TokuDB, our MongoDB and MySQL products. One of its strengths is the ability to get high levels of compression on the stored data. In this post, I’ll explain why that is.

At a high level, one can argue that there isn’t anything special about our compression algorithms. We basically do this: we take large chunks of data, use known compression methods (e.g. zlib, lzma, …

Download PDF Presentation

Thanks to Tim Callaghan for speaking Tuesday night at the Effective MySQL New York meetup on Fractal Tree Indexes : Theory and Practice (MySQL and MongoDB). There was a good turnout and a full room to learn how the TokuDB storage engine from Tokutek is changing how to handle big data in MySQL.

Also interesting is how the same technology has been applied for use in MongoDB including giving MongoDB transactions; a big change for NoSQL.

Related News: …

At tomorrow’s Effective MySQL Meetup, I’ll be presenting “Fractal Tree Indexes : Theory and Practice (MySQL and MongoDB).” The meetup is at 6:30pm Tuesday, May 14, 2013, and will be held at Alley NYC in New York City.

I’ll give an overview on how Fractal Tree® indexes work, and then get into specific product features that Fractal Trees enable in MySQL and MongoDB.  Some benchmarking and customer use-cases will be discussed, but my intent is for this to be a deep technical dive.  Several Tokutek Engineers will also be on hand, so bring any questions you’ve got.

I hope to see you there!