MySQL Bugs: #66889: Memcache interface yields invalid CAS value on GETS with caching policy

Bug #66889	Memcache interface yields invalid CAS value on GETS with caching policy
Submitted:	20 Sep 2012 12:09	Modified:	16 Apr 2019 22:13
Reporter:	Michael Gagnon	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Cluster: Memcached	Severity:	S2 (Serious)
Version:	mysql-cluster-gpl-7.2.7-debian6.0-x86_64	OS:	Linux
Assigned to:	MySQL Verification Team	CPU Architecture:	Any
Tags:	caching, CAS, gets, Memcache

Description:
Attempt to use CAS through the memcache interface on a container configured with cas_column fails under some circumstances. A specific configuration which exposes the incorrect values is provided. When running in verbose mode, no error is reported. Large values that cause usage of the large_values_table can be set and retrieved just fine. Attempt to use 'GETS' yields a CAS value which is invalid and does not correspond to the CAS column; furthermore, the returned CAS appears to be an incrementing value starting from 1, which may be a clue as to the source of the problem.

Using the example container provided with the distro that includes CAS without the large_values_table works fine. The inclusion of the large_value_table initially *appears* to be the cause, though some other quality of my specific configuration below may well be the cause.

How to repeat:
Container configured as follows:
SET name = "big_data", db_schema = "nosql", db_table = "big_data",
       key_columns = "id", value_columns = "data", 
       flags = "flags", expire_time_column = "expire_time",
       cas_column = "cas_value", large_values_table = "big_data_partition"

big_data table structure:
  `id` VARBINARY(64) NOT NULL,
  `data` VARBINARY(1024),
  `cas_value` BIGINT UNSIGNED,
  `flags` INT UNSIGNED NULL,
  `expire_time` TIMESTAMP NULL,
  `ext_id` INT UNSIGNED,
  `ext_size` INT UNSIGNED

big_data_partition table structure:
  `id` INT UNSIGNED AUTO_INCREMENT NOT NULL,
  `part` SMALLINT NOT NULL,
  `content` VARBINARY(13950) NOT NULL

TELNET commands:
set foo 0 0 3
one
STORED

get foo
VALUE foo 0 3
one
END

gets foo
VALUE foo 0 3 1
one
END

cas foo 0 0 3 1
two
EXISTS

using the caching policy, CAS fails; switching to something else such as ndb-only and the CAS is returned properly. Switching back to caching and it returns invalid incrementing numbers again.

This has been narrowed down to the definitive bug inducing variable

Hi,
I cannot reproduce this with any of the modern versions of mysql cluster + memcached.

please retest with modern version of mysql cluster and reopen if necesary

kind regards
Bogdan