capture_persistent_env_contents: Assertion `r == 0' failed with tokudb_cache_size=1024
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Percona Server moved to https://jira.percona.com/projects/PS | Status tracked in 5.7 | |||||
5.6 |
Triaged
|
High
|
Unassigned | |||
5.7 |
Triaged
|
High
|
Unassigned |
Bug Description
If you try to start Percona Server(TokuDB enabled) with tokudb_cache_size equal to 1024 (for eg.), it will fail to start.
Output from Error Log:
2015-10-31 19:29:55 15251 [Note] InnoDB: Percona XtraDB (http://
/mnt/workspace/
db.cc:587 capture_
: No such file or directory
Backtrace: (Note: toku_do_
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/lib/x86_
/usr/sbin/
.
.
.
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/
/usr/sbin/
/lib/x86_
/lib/x86_
/lib/x86_
/usr/lib/
/usr/lib/
/usr/lib/
/usr/lib/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/usr/sbin/
/lib/x86_
/usr/sbin/
You may download the Percona Server operations manual by visiting
http://
in the manual which will help you identify the cause of the crash.
Yes, TokuDB can do numerous bad things when you have an absurdly small cache size. There is no logic that tests cache size against node size either, allowing you to have a cache size that is smaller than a single node size. We should add a more rational minimum cache size and additional logic that validates cache_size > node_size( block_size) *10 > basement_ node_size( read_block_ size)*4 or something similar.