[MDEV-5839] TokuDB tables not properly cleaned on DROP DATABASE Created: 2014-03-12  Updated: 2014-03-26  Resolved: 2014-03-26

Status: Closed
Project: MariaDB Server
Component/s: None
Affects Version/s: 10.0.9
Fix Version/s: 10.0.10

Type: Bug Priority: Major
Reporter: jocelyn fournier Assignee: Sergei Golubchik
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates MDEV-5943 'show table status' does not immediat... Closed

 Description   

Hi,

When a database is dropped with Tokudb tables in it, the tables are not properly dropped.

CREATE DATABASE test1;
use test1;
CREATE TABLE test (a int) ENGINE=TokuDB;
DROP DATABASE test1;
 
CREATE DATABASE test1;
use test1;
CREATE TABLE test (a int) ENGINE=TokuDB;
ERROR 1050 (42S01): Table 'test' already exists
 
l _test1*                                                                                                                                                                                                                        <17:26:09
-rwxrwx--x 1 mysql mysql 32768 mars  12 17:25 _test1_test_main_6a41cf66_2_18.tokudb
-rwxrwx--x 1 mysql mysql 16384 mars  12 17:25 _test1_test_status_6a41cf66_1_18.tokudb

My.cnf :

skip-external-locking
skip-name-resolve
ignore_builtin_innodb
plugin-load-add=ha_innodb
transaction-isolation="READ-UNCOMMITTED"
plugin-load-add=ha_tokudb
tokudb_commit_sync="OFF"
tokudb_cache_size=14G
tokudb_lock_timeout=120000
tokudb_row_format="tokudb_small"
innodb_lock_wait_timeout=120
default_storage_engine=InnoDB
max_allowed_packet=16M
key_buffer_size=128M
table_cache=4096
read_buffer_size=4M
read_rnd_buffer_size=2M
thread_cache_size=80
delayed_insert_limit=500
max_delayed_threads=60
join_buffer_size=2M
sort_buffer_size=2M
delayed_insert_timeout=20
wait_timeout=1800
max_connections=400
back_log=1300
myisam_sort_buffer_size=512M
thread_concurrency=8
tmp_table_size=1G
table_definition_cache = 8192
concurrent_insert=2
innodb_buffer_pool_size=4G
innodb_log_file_size=128M
innodb_log_files_in_group=2
innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=2
innodb_thread_concurrency=16
innodb_read_io_threads=8
innodb_write_io_threads=8
innodb_flush_method=O_DIRECT
innodb_file_per_table=1
innodb_io_capacity=2000
innodb_file_format=Barracuda
myisam-recover         = BACKUP
query_cache_limit=2M
query_cache_size=32M
log-error       = /home/mysql/log/log-error.log

Thanks and regards,
Jocelyn Fournier



 Comments   
Comment by Sergei Golubchik [ 2014-03-23 ]

Tested in 5.5 tree (with TokuDB 7.1.5) — no bug.
Tested in 10.0 tree (with TokuDB 7.1.0) — bug.

So, either it's because of the old TokuDB version in 10.0, and will go away after the next merge (which will happen before 10.0.10 release). Or it may be due to new discovery code in 10.0. Either way, I need to retest after the merge.

Comment by jocelyn fournier [ 2014-03-23 ]

Hi Sergei,

About the remaining .tokudb file in the FS, can I safely remove them ?

Thanks,
Jocelyn

Comment by Sergei Golubchik [ 2014-03-26 ]

The reason for this bug — DROP DATABASE didn't correctly discover all tables in the database, it only looked at .frm files. As a workaround, if you add SELECT * FROM t1 (or any other statement that uses the table) between CREATE TABLE and DROP DATABASE, then the table will be properly removed.

Generated at Thu Feb 08 07:07:26 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.