After upgrading via a binary upgrade from Tokutek binaries to MariaDB 10.0.15, there are various headaches that make this transition problematic. I think at the very least, this is a minor documentation bug, but I think some of the issues might not be too crazy to fix.

The first major issue is that Tokutek stores special values in the .frm row_type. When running SHOW CREATE TABLE against such tables MariaDB crashes.

gdb shows this is caused by MariaDB accessing beyond the end of ha_row_type with an out of bounds create_info.row_type in:

mariadb-10.0.15/sql/sql_show.cc:1970

1970	      packet->append(ha_row_type[(uint) create_info.row_type]);

This is also true if you ALTER a TokuDB table to MyISAM whose .frm inherits the old flags and continue to crash.

A workaround for this issue is to run ALTER TABLE $table ROW_FORMAT=DEFAULT, as long as the tokudb_row_format variable is set appropriately. Selecting from the table otherwise seems to work correctly and gives expected results.

The other issue is with TokuDB clustered indexes, where SHOW CREATE TABLE displays these as FULLTEXT. ALTER TABLE fails with:

ERROR 1464 (HY000) The storage engine TokuDB doesn't support SPATIAL indexes

In this case, I dropped and recreated the clustered indexes which resolved the issue. I imagine the actual data files aren't different, and if a correct .frm could be put into place even this major rebuild might not be necessary. I was hoping to hack a correct. frm into place, but table discovery makes that tricky.

I think at the very least, perhaps some documentation could be added noting this is not a supported upgraded path and mysqldump + munging of the table DDL is necessary. I think perhaps there may be a bug here where MariaDB crashes with bad .frm values, where I would instead expect at least an ERR_NOT_FORM_FILE (1033) error. For comparison, Percona-Server 5.6+TokuDB gives this error with SHOW CREATE TABLE on a TokuDB table with clustered indexes from a Tokutek.com generated datadir.

Of course, ideally if a direct binary upgrade could be supported that would be convenient, particularly in environment with a substantial existing dataset that wish to evaluate MariaDB 10 where rebuilding from logical dumps is a very time consuming process.