| 2016-08-30 04:39:52 |
dennis |
description |
How to reproduce the bug:
Open a new shell "shell1" , and use sysbench to do the modification on the tokudb table, this sysbench
will running through the whole test:
sysbench --mysql-host=127.0.0.1 --mysql-port=3314 --mysql-user=test --mysql-password=test \
--mysql-db=test1 --oltp-tables-count=1 --oltp-table-size=6000000 \
--mysql-table-engine=tokudb --test=tests/db/oltp.lua prepare
open a new shell "shell2" , to check the data file and log file modification of tokudb table in the disk:
cd $datadir
[root@mysql1 data3314]# ls -lh | grep test1
drwx------. 2 mysql mysql 4.0K Aug 30 04:05 test1
rw-rw---. 1 mysql mysql 9.0M Aug 30 04:07 _test1_sbtest1_key_k_1_8c02_1_1c_B_1.tokudb
rw-rw---. 1 mysql mysql 85M Aug 30 04:07 _test1_sbtest1_main_8c02_1_1c_B_0.tokudb
rw-rw---. 1 mysql mysql 64K Aug 30 04:07 test1_sbtest1_status_8bf7_1_1c.tokudb
we can see the log file and data file is changing.
Then open a new shell "shell3" login to the mariadb and acquire the checkpoint lock:
root@localhost:mysql3314.sock 04:07:33 [(none)]>SET TOKUDB_CHECKPOINT_LOCK=ON;
Query OK, 0 rows affected (0.32 sec)
root@localhost:mysql3314.sock 04:07:36 [(none)]>SET global TOKUDB_CHECKPOINT_LOCK=ON;
Query OK, 0 rows affected (0.04 sec)
And during the test, this connection will not quit or broken.
Back to the shell2, we still can see the data file changing!
It seams that, the "TOKUDB_CHECKPOINT_LOCK=ON" fail to stop the data file modification on tokudb. |
OS: centos6.5
DB: percona 5.6.24
How to reproduce the bug:
Open a new shell "shell1" , and use sysbench to do the modification on the tokudb table, this sysbench
will running through the whole test:
sysbench --mysql-host=127.0.0.1 --mysql-port=3314 --mysql-user=test --mysql-password=test \
--mysql-db=test1 --oltp-tables-count=1 --oltp-table-size=6000000 \
--mysql-table-engine=tokudb --test=tests/db/oltp.lua prepare
open a new shell "shell2" , to check the data file and log file modification of tokudb table in the disk:
cd $datadir
[root@mysql1 data3314]# ls -lh | grep test1
drwx------. 2 mysql mysql 4.0K Aug 30 04:05 test1
rw-rw---. 1 mysql mysql 9.0M Aug 30 04:07 _test1_sbtest1_key_k_1_8c02_1_1c_B_1.tokudb
rw-rw---. 1 mysql mysql 85M Aug 30 04:07 _test1_sbtest1_main_8c02_1_1c_B_0.tokudb
rw-rw---. 1 mysql mysql 64K Aug 30 04:07 test1_sbtest1_status_8bf7_1_1c.tokudb
we can see the log file and data file is changing.
Then open a new shell "shell3" login to the mariadb and acquire the checkpoint lock:
root@localhost:mysql3314.sock 04:07:33 [(none)]>SET TOKUDB_CHECKPOINT_LOCK=ON;
Query OK, 0 rows affected (0.32 sec)
root@localhost:mysql3314.sock 04:07:36 [(none)]>SET global TOKUDB_CHECKPOINT_LOCK=ON;
Query OK, 0 rows affected (0.04 sec)
And during the test, this connection will not quit or broken.
Back to the shell2, we still can see the data file changing!
It seams that, the "TOKUDB_CHECKPOINT_LOCK=ON" fail to stop the data file modification on tokudb. |
|
