Have worked through a few row count bugs in recent times with TokuDB (e.g.
TDB-2, etc), and I've only got 1 table left having issues with all known fixes applied.
Running a custom build of MariaDB 10.1.28 (Percona 5.6.37-82.2) with the unreleased fix for
TDB-35 compiled in (just to make sure I have no known row count bugs left).
There's one table that continues to drop logical row count over time.
The unique thing about this table compared to the other tables I have is that it's the only table that is partitioned.
CREATE TABLE `my_table` (
`a` int(10) unsigned NOT NULL AUTO_INCREMENT,
`b` int(10) unsigned NOT NULL,
`c` smallint(5) unsigned NOT NULL,
`d` int(10) unsigned DEFAULT NULL,
`e` varchar(255) DEFAULT NULL,
`h` datetime NOT NULL,
`i` datetime DEFAULT NULL,
`j` datetime DEFAULT NULL,
`expired` tinyint(3) unsigned NOT NULL DEFAULT '0',
PRIMARY KEY (`a`,`expired`),
KEY `b` (`b`),
KEY `d` (`d`),
KEY `e` (`e`)
) ENGINE=TokuDB AUTO_INCREMENT=3075064 DEFAULT CHARSET=utf8 `compression`=tokudb_zlib
/*!50100 PARTITION BY RANGE (expired)
(PARTITION `current` VALUES LESS THAN (1) ENGINE = TokuDB,
PARTITION expired VALUES LESS THAN MAXVALUE ENGINE = TokuDB) */
The partition ('current') drops in row count over time.
Note, this is a slave DB. Using the tokuftdump utility I've managed to graph the logical row count over time and can see it steadily decreasing (see attached graph)
I've had a look across the queries that get executed and nothing really stands out.
There's two scenarios:
Rows will be inserted with expired field as default (0),
Rows will be updated with expired = 1
I tried to reproduce on a smaller scale by moving rows around by changing expired from 0 to 1 in various ways but couldn't reproduce it.
Let me know if any other info will help - hopefully above is enough to theorise where there might be some missing row count logic.