Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.0.9
-
None
-
None
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
Attachments
Issue Links
- duplicates
-
-
- Closed
-
Activity
Hi Sergei,
About the remaining .tokudb file in the FS, can I safely remove them ?
Thanks,
Jocelyn
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.
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.