Showing entries 91 to 100 of 319
« 10 Newer Entries | 10 Older Entries »
Displaying posts with tag: TokuDB (reset)
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.

==1032== Syscall param write(buf) points to uninitialised byte(s)
==1032== at 0x3EFA60E4ED: ??? (in /lib64/
==1032== by 0xB894038: toku_os_full_write(int, void const*, unsigned long) (
==1032== by 0xB83248A: write_outbuf_to_logfile(tokulogger*, __toku_lsn*) (
==1032== by 0xB83326C: toku_logger_maybe_fsync(tokulogger*, __toku_lsn, int, bool) (
==1032== by 0xB8327DE: toku_logger_fsync_if_lsn_not_fsynced(tokulogger*, __toku_lsn) (
==1032== by 0xB8493E6: toku_txn_maybe_fsync_log(tokulogger*, __toku_lsn, bool) (
==1032== by 0xB7B4EBB: toku_txn_commit(__toku_db_txn*, unsigned int, void (*)(__toku_txn_progress*, void*), void*, bool, bool) (
==1032== by 0xB7B55E9: locked_txn_commit_with_progress(__toku_db_txn*, unsigned int, void (*)(__toku_txn_progress*, …
[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 and TokuMX accumulate locks on key ranges while they execute. These locks allow multiple transactions to run concurrently. The locks are released when the transaction commits or aborts.

The locks are stored in an in memory data structure that contains a set of key range and transaction identifier pairs. Since the locks are stored in memory and we want to support arbitrarily large transactions, an algorithm is needed to kick in when the amount of memory used to store locks exceeds a maximum limit. The limit is set when the server is started. The lock escalation algorithm shrinks the total …

[Read more]
Percona Server with TokuDB: Packing 15TB into local SSDs

Two weeks ago we released an Alpha release of Percona Server with TokuDB. Right now I am on a final stage of evaluation of TokuDB for using in our project Percona Cloud Tools and it looks promising.

What is the most attractive in TokuDB? For me it is compression, but not just compression: TokuDB provides great performance over compressed data.

In my synthetic tests I saw a compression ratio of 10:1 (TokuDB LZMA to InnoDB uncompressed), in the real production data it is less, 6:1, but still impressive.

In our servers we have 4 x SSD Crucial M500 960GB combined in RAID5, which give 2877.0 GB of usable space. With TokuDB we should be able to pack around 15TB of raw data. Of course we can try InnoDB compression, …

[Read more]
My Favorite MongoDB Replication Feature: Crash Safety

At an extremely high level, replication in MongoDB and MySQL are similar. Both databases have exactly one machine, the primary (or master), that accepts writes from clients. With a single transaction (or atomic operation, in MongoDB’s case), the tables and oplog (or binary log in MySQL) are modified to reflect the change. The log captures what the change is so other secondaries (or slaves) can read the changes and process them, making the slaves identical to the master. (Note that I am NOT talking about multi-master replication.)

Underneath the covers, their implementations are quite different. And in peeking underneath the covers while developing TokuMX, I learned more about my favorite thing in …

[Read more]
Big trouble with zero-length character columns in TokuDB

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 MySQL Reference Manual says that there are valid uses for such a column, so TokuDB should support it. Unfortunately, we recently found and fixed a bug related to zero length character columns in TokuDB.

A Random Query Generator (RQG) trial generated a table with a ‘char(0)’ column and caused TokuDB to crash when executing an alter table statement that drops the column. The reason for the crash is related to the layout of the values …

[Read more]
March 20 Webinar: How to Scale MySQL for Big Data Applications

You may think that you have to buy, install, and get up to speed on a new database if you want to work with large amounts of data, but you can do more than you think with the MySQL you already have.
Register Now!

SPEAKER: Jon Tobin, Tokutek
DATE: Thursday, March 20th
TIME: 1pm ET

Without having to change your application or do special tuning you can increase performance and save significant time and money when you need to scale.

Join Tokutek’s Jon Tobin as he demonstrates how to use MySQL or MariaDB in Big Data applications by simply upgrading the storage engine with TokuDB, and how to effectively evaluate TokuDB for increased performance, compression and agility.

During this webinar you will learn:

  • How to dramatically increase …
[Read more]
Announcing TokuDB v7.1.5

Yesterday we released TokuDB v7.1.5, which includes the following important features and fixes:

  • Upgraded MySQL and MariaDB to version 5.5.36.
  • Six months of performance improvements to our underlying Fractal Tree indexing.
  • Fixes for bugs, stalls, and behavioral issues reported by users.
  • Fixes for issues identified by the addition of Random Query Generator (RQG) testing.
  • Fixes for issues identified by the addition of Valgrind testing.
  • Full details on the changes in TokuDB v7.1.5 can be found in the release notes section of the TokuDB User’s Guide, available from our documentation page.

As always, you can download the Community and Enterprise Editions from the …

[Read more]
Tokutek and Percona Live 2014

I’ve been a little behind in recent blogging efforts, and realized that in less than a month we’ll be back at Percona Live: MySQL Conference and Expo 2014, aka PLMCE. Last year’s PLMCE was my first, as well as the event where Tokutek announced the open sourcing of TokuDB.

It’s hard to believe that a year has gone by, but the customer adoption in both enterprise and community users has been awesome. TokuDB is available from our website for both MySQL and MariaDB, and is also available directly from MariaDB and …

[Read more]
The MySQL ARCHIVE storage engine – Alternatives

In my previous post I pointed out that the existing ARCHIVE storage engine in MySQL may not be the one that will satisfy your needs when it comes to effectively storing large and/or old data. But are there any good alternatives? As the primary purpose of this engine is to store rarely accessed data in disk space efficient way, I will focus here on data compression abilities rather then on performance.

The InnoDB engine provides compressed row format, but is it’s efficiency even close to the one from that available in archive engine? You can also compress MyISAM tables by using myisampack tool, but that also means a table will be read only after such operation.

Moreover, I don’t trust MyISAM nor Archive when it comes to data durability. Fortunately along came a quite new (open source since April …

[Read more]
The Effects of Database Heap Storage Choices in MongoDB

William Zola over at MongoDB gave a great talk called “The (Only) Three Reasons for Slow MongoDB Performance”. It reminded me of an interesting characteristic of updates in MongoDB. Because MongoDB’s main data store is a flat file and secondary indexes store offsets into the flat file (as I explain here), if the location of a document changes, corresponding entries in secondary indexes must also change. So, an update to an unindexed field that causes the document to move also causes modifications to every secondary index, which, as William points out, can be expensive. If a document has indexed an array, this problem is exacerbated.

What …

[Read more]
Showing entries 91 to 100 of 319
« 10 Newer Entries | 10 Older Entries »