SET global TOKUDB_CHECKPOINT_LOCK=ON will not stop the tokudb data file change
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS |
Invalid
|
Undecided
|
Unassigned |
Bug Description
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-
--mysql-db=test1 --oltp-
--mysql-
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_
rw-rw---. 1 mysql mysql 85M Aug 30 04:07 _test1_
rw-rw---. 1 mysql mysql 64K Aug 30 04:07 test1_sbtest1_
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:
Query OK, 0 rows affected (0.32 sec)
root@localhost:
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_
TokuDB checkpoint lock does not stop data files from changing, it only prevents the checkpoint from occurring. When a dirty node is evicted from memory due to cache pressure, it gets written to disk, The block file map header does not get updated on disk as it does during a checkpoint.
There is one condition where a block file header will get updated even with the checkpointer disabled and that is when an index/dictionary file is closed and evicted from the cache table. This will be addressed in coming versions of Percona Server when the LOCK CHECKPOINT FOR BACKUP is introduced and tokudb_ checkpoint_ lock removed.