Planet MySQL Planet MySQL: Meta Deutsch Español Français Italiano 日本語 Русский Português 中文
10 Newer Entries Showing entries 31 to 40 of 284 10 Older Entries

Displaying posts with tag: TokuView (reset)

November 6 Webinar: 5 Pitfalls to Avoid with MySQL and Big Data
+0 Vote Up -0Vote Down

You love MySQL for its ease of deployment – but are you worried about how your application will perform when it starts to scale?

SPEAKER: Gerry Narvaja, Tokutek
DATE: Wednesday, November 6th
TIME: 1pm ET
Register Now!

Join this interactive webinar with Gerry Narvaja of Tokutek as he walks through the potential pitfalls when using MySQL for Big Data applications, how you can avoid unnecessary tolls on time and resources and tips on how to get the most out of your MySQL applications with open source TokuDB.

Attend this webinar to learn how to:

  • dramatically increase performance without having to rewrite code
  • reduce the total cost of your servers and



  [Read more...]
Problems with Multiple XA Storage Engines in MySQL 5.6
+2 Vote Up -0Vote Down

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
  [Read more...]
Interactive Debugging of Transaction Conflicts with TokuDB
+0 Vote Up -0Vote Down

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 how to use the MySQL information schema to look at the current state of the locks.

Transactions and Locks

TokuDB uses key range locks to implement serializable transactions. These locks are acquired as the transaction progresses. The locks are released when the transaction commits or aborts.

TokuDB stores these locks in a data structure called the lock tree. The lock tree stores the set of range locks granted to each transaction. In addition, the lock tree stores the set of locks that are not granted due to a conflict

  [Read more...]
Announcing TokuDB v7.1
+0 Vote Up -0Vote Down

Today we released TokuDB v7.1, which includes the following important features and fixes:

  • Added ability for users to view lock information via information_schema.tokudb_trx, information_schema.tokudb_locks, and information_schema.tokudb_lock_waits tables.
  • Changed the default compression to zlib and default basement node size to 64K.
  • Changed default analyze time to 5 seconds.
  • Added server variable to control amount of memory allocated for each bulk loader. In prior TokuDB versions each loader allocated 50% of the available TokuDB cache.
  • Changed table close behavior such that all data for the table remains in the cache (and is not flushed immediately).
  • Removed user reported stalls due to cache pressure induced by the bulk loader, lock tree escalation, and a particular open table stall.
  • Several bugs and behavioral issues
  [Read more...]
Introducing TokuMX Clustering Indexes for MongoDB
+1 Vote Up -0Vote Down

Since introducing TokuMX, we’ve discussed benefits that TokuMX has for existing MongoDB applications that require no changes. In this post, I introduce an extension we’ve made to the indexing API: clustering indexes, a tool that can tremendously improve query performance. If I were to speak to someone about clustering indexes, I think the conversation could go something like this…

What is a Clustering Index?

A clustering index is an index that stores the entire document, not just the defined key.

A common example is

  [Read more...]
A TokuDB Stall Caused by Conflicting Transactions When Opening a Table
+0 Vote Up -0Vote Down

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 discuss details about this bug and how it was fixed.  The bug fix will be distributed in TokuDB 7.1.0.

Example
Suppose that we set the tokudb lock timeout to 60 seconds just to exaggerate the stall.

mysql> set global tokudb_lock_timeout=60000;
Query OK, 0 rows affected (0.00 sec)

We then create a simple table.

mysql> create table s (id int primary key);
Query OK, 0 rows affected (0.02







  [Read more...]
October 8 Webinar: Getting Started with MySQL
+0 Vote Up -0Vote Down

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


  [Read more...]
How we built TokuMX
+0 Vote Up -0Vote Down

When I get to talk to people about TokuMX and how it’s an optimized MongoDB, I sometimes get follow-up questions like:

  • “Is it an in-memory proxy?”
  • “Write optimized? So you buffer all of the writes in memory and lose them on crash?”
  • “Did you re-implement the server and match the protocol?”

None of these things describe TokuMX, but it demonstrates that there are many schools of thought on how to optimize databases, and MongoDB in particular. I’d like to elaborate more on what TokuMX really is and how we built it. First, let’s talk about what MongoDB is.

MongoDB consists of a server process that stores data and executes queries, mongod, a sharding router process, mongos, as well as a wire protocol for interacting with these

  [Read more...]
TokuMX Hot Backup – Part 3
+0 Vote Up -0Vote Down

Last week I described TokuDB’s new Hot Backup feature.  This week we are going to briefly discuss the same feature, but as it was added to TokuMX, our version of MongoDB.

Since the Hot Backup library is essentially a shim between MySQL and the Linux kernel, intercepting file system calls for the life of the process, it should be easy to add this to any other system, including TokuMX.  Indeed with our addition of transactions and logging to TokuMX we can gain a consistent backup of any data set at any time.

Unlike MySQL, where system tables use the non-transactional MyISAM storage engine, TokuMX uses internal

  [Read more...]
A TokuDB Stall Caused by a Big Transaction and How It was Fixed
+1 Vote Up -0Vote Down

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 these stalls occurred when a big transaction was committing and the Fractal Tree index software was taking a checkpoint. This problem was fixed in both TokuDB 7.0.3 and TokuMX 1.0.3. Please read on as we describe some details about this bug and how we fixed it. We describe some of the relevant Fractal Tree index algorithms first.

What is a Big Transaction?

Each transaction builds a rollback log as it performs Fractal Tree index operations. The rollback log is maintained in

  [Read more...]
10 Newer Entries Showing entries 31 to 40 of 284 10 Older Entries

Planet MySQL © 1995, 2014, Oracle Corporation and/or its affiliates   Legal Policies | Your Privacy Rights | Terms of Use

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.