Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a TokuDB table that works fine for most queries, but segfaults on others. I did a CHECK TABLE which indicated that the table had errors. However, TokuDB doesn't support REPAIR TABLE. How can I fix a corrupted TokuDB table?

mysql> check table XXX;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1
Current database: XXX

| Table                                          | Op    | Msg_type |     Msg_text |
| XXX.XXX | check | error    | Corrupt  |
1 row in set (14 hours 17 min 55.05 sec)

mysql> repair table XXX;
ERROR 2006 (HY000): MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    2
Current database: XXX

| Table                                          | Op     | Msg_type |     Msg_text                                                |
| XXX.XXX | repair | note     | The storage engine for the table doesn't support repair |
1 row in set (0.84 sec)
share|improve this question

TokuDB does not support the repair table command, just like InnoDB, so you can't repair the table in question. If you don't have a backup or slave to pull from the best you can do is select the rows from the readable portion of the table itself. I'd recommend using "select * from table_name where table_pk < ? into ;" and "select * from table_name where table_pk > ? into ;". You'll need to experiment with the ? for each statement, because once you read the damaged part of the file the server will crash.

share|improve this answer
A script that automates this -… – akuzminsky Feb 24 '14 at 14:46

Since most queries work, your best shot is simply to mysqldump the table

mysqldump --no-data --skip-disable-keys --skip-lock-tables ${DB} ${TB} > ${DUMPSCHM} 
mysqldump --no-create-info --skip-disable-keys --skip-lock-tables ${DB} ${TB} > ${DUMPDATA}

Then, rename the table using

mysql> ALTER TABLE mydb.mytable RENAME mydb.myoldtable;

Then, reload the table using

mysql> source mydb_mytable_schema.sql
mysql> source mydb_mytable_data.sql

Give it a Try (Hope it works) !!!

CAVEAT : Hopefully, there is some TokuDB Doc you can look up at the Tokutek site.

According to one of the Docs, it says:

When using any transaction-safe database, it is essential that you understand the write-caching characteristics of your hardware. TokuDB provides transaction safe (ACID compliant) data storage for MySQL. However, if the underlying operating system or hardware does not actually write data to disk when it says it did, the system can corrupt your database when the machine crashes. For example, TokuDB can not guarantee proper recovery if it is mounted on an NFS volume. It is always safe to disable the write cache, but you may be giving up some performance

If you have this corrupt state due to a system crash or a false positive on a successful write to disk, you will have to consult Tokutek directly as Tokutek is a little out of my wheelhouse.

share|improve this answer
I tried to do a "CREATE TABLE YYY LIKE XXX" and then "INSERT INTO YYY (SELECT * FROM XXX)" and got a segfault on that. Would mysqldump act differently? – Thomas Johnson Feb 23 '14 at 1:10
mysqldump will do a full SELECT * FROM XXX with SQL_NO_CACHE. Try it and see... – RolandoMySQLDBA Feb 23 '14 at 1:14
@ShlomiNoach any insights on corrupt Tokutek tables ??? – RolandoMySQLDBA Feb 23 '14 at 1:19
@RolandoMySQLDBA I haven't encountered any. But maybe the filesystem has a corrupt block? It would be interesting to understand which queries run just fine and which crash. – Shlomi Noach Mar 1 '14 at 5:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.