[MDEV-8977] SELECTS on the same table return inconsistent data Created: 2015-10-21  Updated: 2015-10-26  Resolved: 2015-10-26

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - TokuDB
Affects Version/s: 10.0.16
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Jaime Crespo Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Environment:

Custom packages with MariaDB 10.0.16 and tokudb-7.5.4


 Description   

Reported upstream at: https://tokutek.atlassian.net/browse/DB-890

Huge inconsistency when running these queries:

MariaDB DBSTORE localhost dewiki > pager cat > /dev/null
 
PAGER set to 'cat > /dev/null'
 
MariaDB DBSTORE localhost dewiki > SELECT * FROM revision WHERE rev_page=9023902 and rev_id=147187984;
 
1 row in set (0.00 sec)
 
 
 
MariaDB DBSTORE localhost dewiki > SELECT * FROM revision WHERE rev_page=9023902;
 
Empty set (0.00 sec)

Expected to return the same row even when queried the same row with a partial primary key:

MariaDB DBSTORE localhost dewiki > nopager
 
PAGER set to stdout
 
MariaDB DBSTORE localhost dewiki > SHOW CREATE TABLE revision\G
 
 
 
1. row ***************************
 
Table: revision
 
Create Table: CREATE TABLE `revision` (
 
`rev_id` int(8) unsigned NOT NULL AUTO_INCREMENT,
 
`rev_page` int(8) unsigned NOT NULL DEFAULT '0',
 
`rev_text_id` int(8) unsigned NOT NULL DEFAULT '0',
 
`rev_comment` varbinary(255) NOT NULL,
 
`rev_user` int(5) unsigned NOT NULL DEFAULT '0',
 
`rev_user_text` varbinary(255) NOT NULL DEFAULT '',
 
`rev_timestamp` varbinary(14) NOT NULL DEFAULT '',
 
`rev_minor_edit` tinyint(1) unsigned NOT NULL DEFAULT '0',
 
`rev_deleted` tinyint(1) unsigned NOT NULL DEFAULT '0',
 
`rev_len` int(8) unsigned DEFAULT NULL,
 
`rev_parent_id` int(8) unsigned DEFAULT NULL,
 
`rev_sha1` varbinary(32) NOT NULL DEFAULT '',
 
`rev_content_model` varbinary(32) DEFAULT NULL,
 
`rev_content_format` varbinary(64) DEFAULT NULL,
 
PRIMARY KEY (`rev_page`,`rev_id`),
 
UNIQUE KEY `rev_id` (`rev_id`),
 
KEY `rev_timestamp` (`rev_timestamp`),
 
KEY `page_timestamp` (`rev_page`,`rev_timestamp`),
 
KEY `user_timestamp` (`rev_user`,`rev_timestamp`),
 
KEY `usertext_timestamp` (`rev_user_text`,`rev_timestamp`)
 
) ENGINE=TokuDB AUTO_INCREMENT=147190982 DEFAULT CHARSET=binary ROW_FORMAT=COMPRESSED `compression`='tokudb_zlib'
 
1 row in set (0.00 sec)



 Comments   
Comment by Elena Stepanova [ 2015-10-21 ]

jcrespo,

Would you be able to provide a data dump for the table? It can be uploaded to ftp.askmonty.org/private, this way only MariaDB developers will have access to it.

If it's impossible, please paste the output of 

show table status like 'revision';
 
show index in revision;

In any case, please also run and paste the output of 

EXPLAIN SELECT * FROM revision WHERE rev_page=9023902 and rev_id=147187984;
 
EXPLAIN SELECT * FROM revision WHERE rev_page=9023902;

and attach your cnf file(s).

Thanks.

Comment by Jaime Crespo [ 2015-10-23 ]

As this is a production server, I had to fix replication manually and continue inserting recors- I can no longer reproduce the problem:

mysql> pager cat > /dev/null
 
PAGER set to 'cat > /dev/null'
 
mysql> SELECT * FROM revision WHERE rev_page=9023902 and rev_id=147187984;
 
1 row in set (0.00 sec)
 
 
 
mysql> SELECT * FROM revision WHERE rev_page=9023902;
 
2877 rows in set (0.01 sec)

I highly suspect that this is related to TokuDB's delayed update feature, in which it fails to update the indexes on time to make them consistent with its data on SELECT.

I will leave to you the closing of this Bug (I can always reopen it later if it happens again), although to be fair I wouldn't expect this to be a specific MariaDB issue, but a Toku packing issue or bug. We are suffering several issues with Toku on MariaDB currently: https://phabricator.wikimedia.org/T109069

Comment by Elena Stepanova [ 2015-10-26 ]

jcrespo,
Thanks for the update.
Yes, I will close it for now, but please do comment if you encounter the issue again, and the report will be re-opened. Maybe next time you will be able to collect some info before you have to fix the problem manually.

We are not getting much feedback from TokuDB developers nowadays, so it's difficult to say what they think about this, but we will be tracking the bug you reported to them.

You might also want to consider upgrading – there have been several 10.0 releases since 10.0.16, including both MariaDB bugfixes and TokuDB merges, so maybe the bug you are facing has already been fixed.

Generated at Thu Feb 08 07:31:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.