Issues

Select view

Select search mode

 
41 of 41

MyRocks may cause data corruption after changes in RocksDB 7.10.0

Description

We can get data corruption with Invalid argument: Global seqno is required, but disabled error even without rocksdb_bulk_load (or using rocksdb_bulk_load=0) calling the following from many threads with different tbl01 names :

CREATE TABLE tbl01 (id1 int unsigned NOT NULL,id2 int unsigned NOT NULL,PRIMARY KEY (id1)) ENGINE=ROCKSDB INSERT INTO tbl01 VALUES (1, 1) ALTER TABLE tbl01 ADD INDEX secondary_key (id2) DROP TABLE tbl01

The full script for a stress test that reproduces the issue is at https://github.com/inikep/mysql-5.6/commit/206562b94
Meta said that this is an error in design and whole bulk loading needs to be rewritten. They have no plans to fix it in the near future.

The commit that causes the issue https://github.com/facebook/rocksdb/commit/9502856edd was introduced in RocksDB v7.10.0.
The desciption of the commit from Meta:
Fixed a data race bug of CompactRange() under change_level=true acts on overlapping range with an ongoing file ingestion for level compaction. This will either result in overlapping file ranges corruption at a certain level caught by force_consistency_checks=true or protentially two same keys both with seqno 0 in two different levels (i.e, new data ends up in lower/older level). The latter will be caught by assertion in debug build but go silently and result in read returning wrong result in release build. This fix is general so it also replaced previous fixes to a similar problem for CompactFiles() (#4665), general CompactRange() and auto compaction (commit 5c64fb6 and 87dfc1d).

Percona Server 8.0.33 updated MyRocks/RocksDB to 7.10.2 when Meta created a production tag percona-202301.

It seems that MariaDB reverted from RocksDB v8.1.1 to v6.8.0 https://github.com/MariaDB/server/commit/49b5a2b3602e13a
It may be related to the issues described in this ticket.

Related JIRA: https://jira.mariadb.org/browse/MDEV-30610

Environment

None

AFFECTED CS IDs

CS0043699

Details

Assignee

Reporter

Needs QA

Yes

In progress time

3

Start date

Time tracking

1m logged

Priority

Smart Checklist

Created February 17, 2025 at 8:21 AM
Updated February 26, 2025 at 5:48 PM

Activity

Show:

Julia Vural February 26, 2025 at 5:48 PM

created a branch with reverting the commit that caused the issue mentioned in this ticket. We are tracking the work for revert and asking customer to try it with ticket https://perconadev.atlassian.net/browse/PS-9698

Przemyslaw Skibinski February 19, 2025 at 1:29 PM

In PS 8.0.36 we upgraded MyRocks to percona-202305 which uses RocksDB v8.5.1 and this is the current version we are using.
I reverted  https://github.com/facebook/rocksdb/commit/9502856edd that introduces a data corruption from RocksDB v8.5.1 and I'm surprised because:

  • code compiles without issues

  • all MTR tests work fine on my local machine (I only did 2 rewrites because of changed error descriptions)

Przemyslaw Skibinski February 19, 2025 at 7:50 AM

I reverted the commit that causes the issue in MyRocks.
The PS 8.0.34 branch available at https://github.com/percona/percona-server/tree/release-8.0.34-26_arm-fixed contains 2 fixes:

  1. A fix for https://perconadev.atlassian.net/browse/PS-9667 backported from MySQL 8.0.37 -> not tested (only MTR tests)

  2. A fix for https://perconadev.atlassian.net/browse/PS-9680 -> all MTR tests passed successfully on my local machine

Flag notifications