TokuDB renaming table to nonexistent DB destroys table

[Kai]

tokudb_version 5.6.33-79.0

ALTER TABLE foo.bar RENAME zot.bar;

If table "zot" does not exist, the table is destroyed instead of giving an error message.

This occurs with tokudb_dir_per_db both ON and OFF. All other TokuDB variables have not been changed at any point.

[Shahriyar Rzayev (rzayev-sehriyar)]

With Innodb it is something like:

mysql [localhost] {root} (dbtest) > alter table dbtest.sbtest1 rename fff.sbtest1;
ERROR 1025 (HY000): Error on rename of './dbtest/sbtest1' to './fff/sbtest1' (errno: -1 - Unknown error -1)

But the base table will remain good:
mysql [localhost] {root} (dbtest) > show tables;
+------------------+
| Tables_in_dbtest |
+------------------+
| sbtest1 |
+------------------+
1 row in set (0.00 sec)

mysql [localhost] {root} (dbtest) > select count(*) from sbtest1;
+----------+
| count(*) |
+----------+
| 10000 |
+----------+
1 row in set (0.04 sec)

http://bugs.mysql.com/bug.php?id=84000

[Tomislav Plavcic (tplavcic)]

I can't reproduce the missing data part but I could get a crash with both 5.6 and 5.7 when tokudb_dir_per_db=ON (which is default in 5.7)

Here's my output:
PS 5.7.16:
==========
mysql> show variables like 'tokudb_dir_per_db';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| tokudb_dir_per_db | ON |
+-------------------+-------+
1 row in set (0.00 sec)

mysql> use test;
Database changed

mysql> create table t1 (a int) engine=TokuDB;
Query OK, 0 rows affected (0.29 sec)

mysql> insert into t1 values (1),(2),(3);
Query OK, 3 rows affected (0.09 sec)
Records: 3 Duplicates: 0 Warnings: 0

mysql> alter table test.t1 rename nema.t1;
ERROR 2013 (HY000): Lost connection to MySQL server during query

Version: '5.7.16-10' socket: '/home/tomislav.plavcic/Percona-Server-5.7.16-10-Linux.x86_64.ssl100/socket.sock' port: 19636 Percona Server (GPL), Release 10, Revision a0c7d0d
/mnt/workspace/percona-server-5.7-binaries-release/label_exp/debian-wheezy-x64/percona-server-5.7.16-10/storage/tokudb/PerconaFT/src/ydb.cc:2917 can_acquire_table_lock: Assertion `r == 0' failed (errno=2) (r=2)

+bt
#0 __pthread_kill (threadid=<optimized out>, signo=6) at ../sysdeps/unix/sysv/linux/pthread_kill.c:62
#1 0x0000000000943fad in handle_fatal_signal (sig=6) at /mnt/workspace/percona-server-5.7-binaries-release/label_exp/debian-wheezy-x64/percona-server-5.7.16-10/sql/signal_handler.cc:223
#2 <signal handler called>
#3 0x00007f44de067428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#4 0x00007f44de06902a in __GI_abort () at abort.c:89
#5 0x00007f44d28d6578 in toku_do_backtrace_abort() [clone .85905] () at /mnt/workspace/percona-server-5.7-binaries-release/label_exp/debian-wheezy-x64/percona-server-5.7.16-10/storage/tokudb/PerconaFT/portability/toku_assert.cc:14
7
#6 0x00007f44d291e015 in toku_do_assert_zero_fail (expr=expr@entry=2, expr_as_string=expr_as_string@entry=0x7f44d299ec53 "r", function=function@entry=0x7f44d29c18f0 <_ZZL22can_acquire_table_lockP13__toku_db_envP13__toku_db_txnPKcE
12__FUNCTION__.5611.13650> "can_acquire_table_lock", file=file@entry=0x7f44d29aadb0 "/mnt/workspace/percona-server-5.7-binaries-release/label_exp/debian-wheezy-x64/percona-server-5.7.16-10/storage/tokudb/PerconaFT/src/ydb.cc", line
=line@entry=2917, caller_errno=<optimized out>) at /mnt/workspace/percona-server-5.7-binaries-release/label_exp/debian-wheezy-x64/percona-server-5.7.16-10/storage/tokudb/PerconaFT/portability/toku_assert.cc:177
#7 0x00007f44d297f88a in can_acquire_table_lock (iname_in_env=<optimized out>, txn=0x7f449d8a5200, env=0x0) at /mnt/workspace/percona-server-5.7-binaries-release/label_exp/debian-wheezy-x64/percona-server-5.7.16-10/storage/tokudb/
PerconaFT/src/ydb.cc:2917
#8 env_dbrename(__toku_db_env*, __toku_db_txn*, char const*, char const*, char const*, unsigned int) [clone .part.69.4607] (env=env@entry=0x7f44d3bd8600, txn=txn@entry=0x7f449d8a5200, fname=fname@entry=0x7f449d82e320 "./test/t1-ma
in", dbname=dbname@entry=0x0, newname=0x7f449d82e520 "./nema/t1-main", flags=flags@entry=0) at /mnt/workspace/percona-server-5.7-binaries-release/label_exp/debian-wheezy-x64/percona-server-5....

[George Ormond Lorch III (gl-az)]

See also https://tokutek.atlassian.net/browse/DB-1030

InnoDB works because InnoDB engine detects movement to non-existent db/folder. How this passes through the server code without any validation down to the SE is beyond me and seem like there should be an upstream issue reported as well (one that will likely never get fixed).

[Tomislav Plavcic (tplavcic)]

@Kai
It seems we can't reproduce your case when table gets destroyed, can you give exact steps to reproduce this or at least more info.
For example, did you have tokudb_dir_per_db=OFF before creating the table and then changed this to tokudb_dir_per_db=ON and then did alter table or you always had it at one setting during the case?
Did you get a crash also when data was missing or just the error and table was gone?
Thanks!

[Sveta Smirnova (svetasmirnova)]

I also cannot repeat described behavior. Also https://tokutek.atlassian.net/browse/DB-1030 has been resolved and there is no crash anymore.

Please check with current versions 5.6.35 and 5.7.17 and if bug still repeatable for you provide repeatable test case. I tested with:

create table t1 (id int auto_increment primary key not null) engine=tokudb;
insert into t1 values(1);
alter table test.t1 rename foo.t1;
--Got error 1025
select * from t1;
id
1
drop table t1;

set global tokudb_dir_per_db=true;
create table t1 (id int auto_increment primary key not null) engine=tokudb;
insert into t1 values(1);
alter table test.t1 rename foo.t1;
--Got error 1025
select * from t1;
id
1
drop table t1;

[Vlad Lesin (vlad-lesin)]

Fixed:

https://github.com/percona/PerconaFT/pull/365
https://github.com/percona/percona-server/pull/1275
https://github.com/percona/percona-server/pull/1276

[Shahriyar Rzayev (rzayev-sehriyar)]

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-397