Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make RrocksDB checksum type configurable #3793

Conversation

hangc0276
Copy link
Contributor

Motivation

Fix #3734 (comment)

We have two rocksDB tables, one for the ledger index, and another for the entry log location.

  • ledger index RocksDB table: Use the default table option, and the checksum is kCRC32c
  • entry log location RocksDb table: Use configured table option, and the checksum is kxxHash

When we upgrade the RocksDB version from 6.10.2 to 7.9.2, the new RocksDB version's default table checksum has changed from kCRC32c to kXXH3, and kXXH3 only supported since RocksDB 6.27. The RocksDB version rollback to 6.10.2 will be failed due to RocksDB 6.10.2 doesn't support the kXXH3 checksum type.

Modifications

In this PR, I make the RocksDB checksum type configurable. But there is one change that will change the ledger index RocksDB table's checksum type from the default kCRC32c to kxxHash. I have tested the compatibility of the two checksum types in and between multiple RocksDB versions, it works fine.

After setting the two RocksDB table's checksum type to kxxHash, the RocksDB's version upgraded from 6.10.2 to 7.9.2, and rolling back to 6.10.2 works fine.

More to discuss

When writing the unit test to read the table checksum type from RocksDB configuration files, it failed. I found the related issue on RocksDB: facebook/rocksdb#5297
The related PR: facebook/rocksdb#10826

It means we still can't load RocksDB table options from configuration files. Maybe I missed some parts about reading RocksDB table options from the configuration file.

If this issue exists, we do NOT recommend users configure RocksDB configurations through configuration files.

@merlimat @eolivelli @dlg99 Please help take a look, thanks.

@hangc0276 hangc0276 self-assigned this Feb 21, 2023
@hangc0276 hangc0276 added this to the 4.16.0 milestone Feb 21, 2023
@codecov-commenter
Copy link

codecov-commenter commented Feb 21, 2023

Codecov Report

Merging #3793 (830d57f) into master (128c52e) will increase coverage by 7.85%.
The diff coverage is 40.00%.

@@             Coverage Diff              @@
##             master    #3793      +/-   ##
============================================
+ Coverage     60.40%   68.25%   +7.85%     
- Complexity     5856     6751     +895     
============================================
  Files           473      473              
  Lines         40906    40910       +4     
  Branches       5232     5232              
============================================
+ Hits          24711    27925    +3214     
+ Misses        13981    10727    -3254     
- Partials       2214     2258      +44     
Flag Coverage Δ
bookie 39.78% <40.00%> (+0.04%) ⬆️
client 44.08% <0.00%> (?)
remaining 29.53% <0.00%> (-0.01%) ⬇️
replication 41.30% <0.00%> (-0.04%) ⬇️
tls 20.89% <0.00%> (-0.02%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...per/bookie/storage/ldb/KeyValueStorageRocksDB.java 71.31% <40.00%> (-0.73%) ⬇️
.../main/java/org/apache/bookkeeper/util/ZkUtils.java 78.35% <0.00%> (-3.10%) ⬇️
...keeper/replication/AuditorCheckAllLedgersTask.java 53.74% <0.00%> (-2.73%) ⬇️
...apache/bookkeeper/verifier/BookkeeperVerifier.java 86.06% <0.00%> (-1.82%) ⬇️
...he/bookkeeper/bookie/InterleavedLedgerStorage.java 77.44% <0.00%> (-1.51%) ⬇️
...g/apache/bookkeeper/bookie/DefaultEntryLogger.java 79.59% <0.00%> (-0.69%) ⬇️
...in/java/org/apache/bookkeeper/bookie/FileInfo.java 78.59% <0.00%> (-0.37%) ⬇️
...va/org/apache/bookkeeper/versioning/Versioned.java 75.00% <0.00%> (ø)
...rg/apache/bookkeeper/bookie/IndexInMemPageMgr.java 87.25% <0.00%> (+0.38%) ⬆️
...g/apache/bookkeeper/zookeeper/ZooKeeperClient.java 77.62% <0.00%> (+0.40%) ⬆️
... and 126 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@Test
public void testReadChecksumTypeFromBookieConfiguration() throws Exception {
ServerConfiguration configuration = new ServerConfiguration();
configuration.setProperty("dbStorage_rocksDB_checksum_type", "kxxHash");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can remove configuration.setProperty("dbStorage_rocksDB_checksum_type", "kxxHash"); to verify the default value is kxxHash.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@hangc0276 hangc0276 force-pushed the chenhang/make_rocksdb_checksum_type_configurable branch from 558ae30 to 830d57f Compare March 6, 2023 03:03
@hangc0276 hangc0276 merged commit 3844bf1 into apache:master Mar 6, 2023
dlg99 pushed a commit to datastax/bookkeeper that referenced this pull request Jun 28, 2024
### Motivation
Fix apache#3734 (comment)

We have two rocksDB tables, one for the ledger index, and another for the entry log location.
 - ledger index RocksDB table: Use the default table option, and the checksum is `kCRC32c`
 - entry log location RocksDb table: Use configured table option, and the checksum is `kxxHash`

When we upgrade the RocksDB version from 6.10.2 to 7.9.2, the new RocksDB version's default table checksum has changed from `kCRC32c` to `kXXH3`, and `kXXH3` only supported since RocksDB 6.27. The RocksDB version rollback to 6.10.2 will be failed due to RocksDB 6.10.2 doesn't support the `kXXH3` checksum type.

### Modifications
In this PR, I make the RocksDB checksum type configurable. But there is one change that will change the ledger index RocksDB table's checksum type from the default `kCRC32c` to `kxxHash`. I have tested the compatibility of the two checksum types in and between multiple RocksDB versions, it works fine.

After setting the two RocksDB table's checksum type to `kxxHash`, the RocksDB's version upgraded from 6.10.2 to 7.9.2, and rolling back to 6.10.2 works fine.

### More to discuss
When writing the unit test to read the table checksum type from RocksDB configuration files, it failed. I found the related issue on RocksDB: facebook/rocksdb#5297
The related PR: facebook/rocksdb#10826

It means we still can't load RocksDB table options from configuration files. Maybe I missed some parts about reading RocksDB table options from the configuration file.

If this issue exists, we do **NOT** recommend users configure RocksDB configurations through configuration files.

@merlimat @eolivelli @dlg99 Please help take a look, thanks.

(cherry picked from commit 3844bf1)
dlg99 pushed a commit to datastax/bookkeeper that referenced this pull request Jul 2, 2024
### Motivation
Fix apache#3734 (comment)

We have two rocksDB tables, one for the ledger index, and another for the entry log location.
 - ledger index RocksDB table: Use the default table option, and the checksum is `kCRC32c`
 - entry log location RocksDb table: Use configured table option, and the checksum is `kxxHash`

When we upgrade the RocksDB version from 6.10.2 to 7.9.2, the new RocksDB version's default table checksum has changed from `kCRC32c` to `kXXH3`, and `kXXH3` only supported since RocksDB 6.27. The RocksDB version rollback to 6.10.2 will be failed due to RocksDB 6.10.2 doesn't support the `kXXH3` checksum type.

### Modifications
In this PR, I make the RocksDB checksum type configurable. But there is one change that will change the ledger index RocksDB table's checksum type from the default `kCRC32c` to `kxxHash`. I have tested the compatibility of the two checksum types in and between multiple RocksDB versions, it works fine.

After setting the two RocksDB table's checksum type to `kxxHash`, the RocksDB's version upgraded from 6.10.2 to 7.9.2, and rolling back to 6.10.2 works fine.

### More to discuss
When writing the unit test to read the table checksum type from RocksDB configuration files, it failed. I found the related issue on RocksDB: facebook/rocksdb#5297
The related PR: facebook/rocksdb#10826

It means we still can't load RocksDB table options from configuration files. Maybe I missed some parts about reading RocksDB table options from the configuration file.

If this issue exists, we do **NOT** recommend users configure RocksDB configurations through configuration files.

@merlimat @eolivelli @dlg99 Please help take a look, thanks.

(cherry picked from commit 3844bf1)
Ghatage pushed a commit to sijie/bookkeeper that referenced this pull request Jul 12, 2024
### Motivation
Fix apache#3734 (comment)

We have two rocksDB tables, one for the ledger index, and another for the entry log location.
 - ledger index RocksDB table: Use the default table option, and the checksum is `kCRC32c`
 - entry log location RocksDb table: Use configured table option, and the checksum is `kxxHash` 

When we upgrade the RocksDB version from 6.10.2 to 7.9.2, the new RocksDB version's default table checksum has changed from `kCRC32c` to `kXXH3`, and `kXXH3` only supported since RocksDB 6.27. The RocksDB version rollback to 6.10.2 will be failed due to RocksDB 6.10.2 doesn't support the `kXXH3` checksum type.

### Modifications
In this PR, I make the RocksDB checksum type configurable. But there is one change that will change the ledger index RocksDB table's checksum type from the default `kCRC32c` to `kxxHash`. I have tested the compatibility of the two checksum types in and between multiple RocksDB versions, it works fine.

After setting the two RocksDB table's checksum type to `kxxHash`, the RocksDB's version upgraded from 6.10.2 to 7.9.2, and rolling back to 6.10.2 works fine.

### More to discuss
When writing the unit test to read the table checksum type from RocksDB configuration files, it failed. I found the related issue on RocksDB: facebook/rocksdb#5297
The related PR: facebook/rocksdb#10826

It means we still can't load RocksDB table options from configuration files. Maybe I missed some parts about reading RocksDB table options from the configuration file. 

If this issue exists, we do **NOT** recommend users configure RocksDB configurations through configuration files.

@merlimat @eolivelli @dlg99 Please help take a look, thanks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants