Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
10.0.26
-
centos6.5, mariadb 10.0.26
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.