Corrupt frm after upgrade from MySQL 5.5 to MySQL 5.6 (with tokudb)

MySQL & MariaDB Percona Server for MySQL 5.6
1

I am going to upgrade “mysql-5.5.41-tokudb-7.5.5-linux-x86_64” to “Percona-Server-5.6.36-rel82.0-Linux.x86_64.ssl101”.
(Not dump & load , just copy datafiles to Percona server 5.6)

But partitioned table’s frm can not be recognized with Percona server 5.6.

MySQL 5.5
CREATE TABLE partitioned (
c1 int(11) NOT NULL AUTO_INCREMENT,
createDate datetime NOT NULL,
c2 int(11) NOT NULL,
c3 varchar(100) DEFAULT NULL,
PRIMARY KEY (c1,createDate)
) ENGINE=TokuDB AUTO_INCREMENT=1572824 DEFAULT CHARSET=utf8mb4 ROW_FORMAT=TOKUDB_QUICKLZ
PARTITION BY RANGE COLUMNS(createDate)
(PARTITION p201502 VALUES LESS THAN (‘2015-02-01 00:00:00’) ENGINE = TokuDB,
PARTITION p201503 VALUES LESS THAN (‘2015-03-01 00:00:00’) ENGINE = TokuDB,
PARTITION p201504 VALUES LESS THAN (‘2015-04-01 00:00:00’) ENGINE = TokuDB,
PARTITION p201505 VALUES LESS THAN (‘2015-05-01 00:00:00’) ENGINE = TokuDB);

insert into part values (100, ‘2015-01-01 01:01:01’, 100, ‘100’);

MySQL 5.6
show create table partitioned;
==> MySQL 5.6 complained that “mysqld: Incorrect information in file: ‘./temp/part.frm’”
So, I created new table with same structure of ‘partitioned’, and copied(overwrited) frm and par files to partitioned table’s (as guided from https://tokutek.atlassian.net/browse/DB-882).

After overwriting frm and par file, show create table command works properly.
But selecting data is trouble like…

mysql-5.6> select * from part;
±----±--------------------±----------±-----+
| c1 | createDate | c2 | c3 |
±----±--------------------±----------±-----+
| 100 | 2205-06-31 31:63:61 | 808464640 | |
±----±--------------------±----------±-----+
1 row in set (0.00 sec)

I don’t know why. but not partitioned table is working correctly. so I think it’s FRM file’s issue.
Looks like I can upgrade to percona server 5.6 if this frm issue can be solved.

Is there anyway to migrate FRM file of mysql 5.5 tokudb table to mysql 5.6 without dump/load .
There’s huge data and no replication, so we need to upgrade percona server 5.6 without stopping service several days.

Thanks.

2

This is not a supported upgrade path unfortunately. Tokutek made some decisions in their implementation and it prevents such an upgrade from succeeding. You can not cross ‘variants’ with TokuDB data files, i.e. you can not go from Tokutek build of MySQL to Percona Server or MariaDB or back as there are some data file format differences. Then there are also 5.5 to 5.6 temporal data type format changes for which there is no upgrade path at all within TokuDB. Hopefully you have a backup as it is possible that once an alternate variant touches the data files, they could be irreparably damaged. The only way to move from the Tokutek MySQL build to Percona is through a logical dump and reload.